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I.  INTRODUCTION 


In  recent  years,  more  and  more  attention  has  been  placed  on  developing  better 
methods  for  the  production  of  software.  This  results  from  the  fact  that  hardware  has 
simultaneously  dropped  in  price  dramatically  and  increased  in  performance  while 
software  has  continued  to  be  plagued  by  cases  of  bug  prone  productions,  incomplete 
designs  that  don't  function  as  desired  and  in  some  high  profile  incidents,  software 
projects  that  had  to  be  abandoned  as  hopeless.  Often  the  culprit  in  these  cases  is  a 
poor  understanding  of  the  user's  requirements.  This  leads  to  incomplete  or  erroneous 
functionality  in  a  software  system  that,  with  traditional  methods,  remains  undiscovered 
until  near  the  end  of  development  when  the  user  sees  a  working  product  for  the  first 
time.  At  this  point,  it  is  difficult  and  very  expensive  to  correct  requirement  deficiencies. 
This  situation  led  to  the  concept  of  prototyping  software  systems  early  in  development 
so  that  requirements  could  be  validated  in  time  to  easily  make  changes  before  problems 
became  too  deeply  rooted.  The  first  prototypes  were  largely  coded  manually.  This 
made  timely  analysis  difficult.  Today,  technology  has  matured  to  the  point  that 
automatic  generation  of  prototypes  is  not  only  feasible  but  practical  as  well  [CHAV95] . 
As  the  software  development  process  has  become  more  and  more  distributed,  a  need 
has  arisen  for  distributed  prototyping  tools. 

A.  BACKGROUND 

In  the  traditional  waterfall  method  of  software  development,  requirements 
analysis  and  subsequent  design  were  done  before  little,  if  any,  actually  coding  was 
done.  This  helped  to  preclude  the  analysis  and  design  being  unduly  influenced  by 
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implementation  constraints  or  biases.  However,  the  draw  back  was  that  once 
promulgated,  these  decisions  tended  to  be  seen  as  set  in  stone.  Even  if  they  were 
reviewed  later  in  the  development  cycle,  it  was  difficult  to  update  them.  The  major 
drawback  though  was  that  the  customer  only  saw  their  requirements  on  paper.  Possibly 
they  had  some  conceptual  drawings  of  an  interface,  but  clearly  that  was  not  interactive 
at  all.  This  led  to  customers  who  didn't  get  hands-on  experience  with  their  product  until 
some  sort  of  alpha  version  was  developed.  At  this  point  the  project  was  nearing 
completion  and  making  fundamental  changes,  even  simple  ones,  was  very  difficult.  The 
result  was  expensive  software  that  did  not  perform  as  the  customer  actually  wanted  it  to 
and  was  probably  delivered  late.  Clearly  there  had  to  be  a  better  way  to  develop 
software. 

That  better  way  is  prototyping.  The  idea  is  simple  but  powerful.  Take  the 
customer's  requirements  and  create  executable  models  to  allow  customers  to  clarify  the 
desired  system  functionality.  The  tremendous  advantage  of  this  was  the  customer  had 
a  model  not  drawn  on  paper  but  one  that  could  be  interacted  with  on  the  computer.  The 
developer  could  use  a  prototype  to  help  explain  the  system  design  to  the  customer. 
Customer  feedback  was  immediate  and  clarification  of  requirements  by  the  customer 
much  clearer.  Since  the  investment  of  time  and  effort  to  produce  a  prototype  was 
relatively  small  and  it  was  early  in  the  development  process,  changes  that  the  customer 
wanted  were  easily  accommodated.  However,  the  prototype  was  still  largely  a  hand- 
coded  product.  In  order  to  reach  its  full  potential,  prototyping  would  have  to  become 
even  more  timely. 
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Automation  was  the  only  way  for  prototyping,  to  become  timelier.  This  necessity 
led  to  the  development  of  the  Computer  Aided  Prototyping  System  (CAPS)  at  the  Naval 
Postgraduate  School  [LUQI88a,LUQI96].  The  goal  of  CAPS  is  to  improve  the  efficiency 
and  accuracy  of  evolutionary  software  development  by  providing  tools  that  make  it 
possible  for  the  developer  to  quickly  and  systematically  construct  and  execute 
prototypes  [DAMP92].  Much  effort  has  gone  into  achieving  the  goal  of  automating  the 
prototyping  process  and  the  results  thus  far  are  impressive.  However,  the  biggest 
drawback  to  wider  use  of  CAPS  is  that  it  remains  a  local  system.  This  makes  it  difficult, 
if  not  impossible,  to  coordinate  a  large  project  with  many  designers.  The  reality  of 
software  production  today  is  that  a  team  that  is  geographically  dispersed  will  most  likely 
carry  out  the  development  of  any  particular  system.  Thus  to  unlock  the  full  potential  of 
CAPS,  it  is  necessary  to  implement  it  in  a  distributed,  network  environment. 

B.  THESIS  OBJECTIVES 

A  significant  amount  of  research  has  gone  into  developing  CAPS.  However, 
today  CAPS  is  implemented  on  a  stand  alone  UNIX  system.  This  arrangement  has 
served  the  research  done  to  date  quite  well.  To  unlock  the  potential  that  exists  in  CAPS 
though,  it  must  become  more  versatile.  This  means  making  CAPS  available  to  a  wider 
client  base  and  this  requires  distributing  it  over  a  network.  That  could  be  simply  a  local 
area  network  (LAN)  but  that  would  only  be  a  half  step.  It  should  also  be  deployable 
over  a  wide  area  network  (WAN)  since  more  and  more  collaborators  on  projects  are 
located  over  physically  remote  sites.  Any  discussion  about  a  LAN  or  especially  a  WAN 
must  first  acknowledge  the  certainty  that  the  network  will  be  heterogeneous.  Thus 
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many  of  the  assumptions  made  when  CAPS  was  a  stand-alone  system  will  no  longer  be 
valid. 

Any  architecture  and  subsequent  implementation  of  CAPS  on  a  network  will  have 
to  address  many  requirements.  The  high  reliability  required  in  a  prototyping  system 
such  as  CAPS  will  be  an  even  greater  challenge  in  a  distributed  environment.  Isolating 
errors  in  a  stand-alone  system  is  relatively  easy  when  compared  to  the  same  process  in 
a  distributed  environment.  As  the  distributed  environment  grows,  high  availability 
becomes  more  important.  Since  the  network  is  sure  to  be  heterogeneous,  the 
correctness  of  the  system  will  depend  on  maintaining  the  consistency  and  integrity  of 
the  data  as  it  is  passed  throughout  an  environment  that  includes  a  variety  of  operating 
systems,  machine  hardware  and  programming  languages. 

These  are  only  a  few  of  the  more  obvious  obstacles  to  providing  a  distributed 
implementation  of  CAPS.  Some  of  the  problems  will  have  straightforward,  readily 
available  answers.  But  due  to  the  uniqueness  of  CAPS,  many  will  not.  Thus  a 
comprehensive  requirements  analysis  is  imperative  if  CAPS  is  to  be  successfully 
deployed  in  a  distributed  environment. 

1 .  Requirements  for  a  Distributed  CAPS 

With  CAPS  operating  on  a  stand-alone  UNIX  system,  it  is  possible  to  make  many 
simplifying  assumptions.  Consequently,  much  of  the  current  design  will  have  to  be 
reexamined.  However,  distributing  CAPS  is  more  complicated  than  simply  taking  the 
current  system  and  putting  it  on  a  network.  Before  creating  a  design  and  architecture, 
the  requirements  themselves  must  be  reevaluated.  It  is  possible,  indeed  almost  certain, 
that  adapting  CAPS  to  a  distributed  environment  will  alter  many  of  the  requirements  that 
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led  to  the  creation  of  CAPS.  Below  are  characteristics  that  need  to  included  in  the 
requirements  analysis  for  distributing  CAPS. 

What  will  be  the  nature  of  the  actual  physical  environment?  The  degree  of 
transparency  must  be  decided.  It  is  assumed  that  any  distributed  network  will  be 
heterogeneous  but  that  doesn't  mean  that  it  will  necessarily  support  any  hardware  or 
operating  system  that  is  connected  to  the  network.  Exactly  what  will  be  supported  must 
be  determined.  Will  it  be  installed  on  a  LAN,  WAN  or  some  other  network  design?  The 
amount  of  fault  tolerance  must  be  considered.  System  performance  encompasses 
several  issues.  What  is  the  minimum  system  hardware  requirement  to  be  enforced? 
The  amount  of  latency  that  can  be  tolerated  will  affect  the  design  and  must  be 
determined.  Is  scalability  important  to  a  distributed  CAPS?  It  may  be  possible  to 
decide  that  there  are  practical  limits  to  the  size  of  any  useful  implementation.  As  with 
any  distributed  system,  security  becomes  a  much  bigger  concern.  Certainly  cost  is  a 
consideration  if  you  want  to  widely  deploy  any  system,  as  is  ease  of  use.  Ease  of  use 
will  also  include  questions  about  the  effectiveness  of  training.  A  key  requirement  will  be 
the  constraints  placed  on  what  language  reusable  components  can  be  written  in.  The 
healthy  population  of  the  database  of  reusable  components  is  critical  to  CAPS  reaching 
its  full  potential,  thus  the  impediments  to  achieving  that  goal  should  be  as  few  as 
possible. 

2.  Design  Issues  for  a  Distributed  CAPS 

The  nature  of  the  distributed  architecture  will  determine  many  of  the  design 
specifics.  What  type  of  architecture  is  best  for  CAPS?  The  architecture  can  be 
centralized,  replicated  throughout  the  network,  or  something  in  between.  One  of  the 
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most  fundamental  design  questions  deals  with  how  to  handle  components.  This  is 
much  more  complicated  and  less  straightforward  than  in  an  undistributed  system.  How 
different  components  communicate  with  each  other  must  be  decided  and  will  be 
affected  by  where  they  are  located.  Closely  associated  with  the  question  of 
communication  is  what  degree  of  mobility  components  will  have  and  how  they  will  be 
synchronized.  Components  are  not  the  only  entities  that  must  specify  their  behavior  in 
a  distributed  environment.  Data  itself  is  severely  influenced  by  the  architectural  design. 
What  sort  of  access  will  users  have  to  data  in  a  distributed  CAPS?  It  can  be  shared, 
distributed  or  some  form  of  shared-distributed  [PROT96].  The  details  of  how  persistent 
storage  will  operate  must  be  consistent  with  the  handling  of  data. 

There  is  a  collection  of  other  design  questions  to  be  answered  in  addition  to  how 
components  and  data  will  behave.  The  mechanism  for  creation  and  subsequent 
destruction  of  process  and  threads  must  be  specified.  This  must  accommodate  not  only 
a  distributed  environment  but  the  possibility  of  multi-processor  machines  within  the 
network.  With  processes  and  data  distributed  throughout  a  network,  provisions  must  be 
made  for  handling  distributed  exceptions.  At  the  management  level,  distributed  CAPS 
must  provide  for  version  control  and  merging  of  distributed  data.  The  strategy  for 
dealing  with  both  of  these  functions  will  be  critical  to  successfully  distributing  CAPS.  It 
will  be  futile  to  take  advantage  of  the  improved  productivity  offered  by  distributing  CAPS 
if  a  coherent,  correct  prototype  is  not  the  ultimate  product. 

A  final  consideration  throughout  the  design  process  will  be  how  or  whether  to 
reuse  parts  of  the  existing  CAPS  system.  Clearly,  some  of  it  must  be  radically 
reengineered  to  support  operations  in  a  distributed  network.  However,  much  of  the 
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current  system  may  be  useable  in  a  distributed  environment.  Deciding  what  to  keep 
unchanged  and  what  to  alter  will  be  a  constant  balancing  act.  Any  design  must  weigh 
the  performance  improvement  associated  with  any  change  to  the  existing  system 
against  the  cost  of  implementing  that  change. 
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II.  BACKGROUND 


The  history  of  software  prototyping  shares  many  similarities  with  the  larger 
subject  of  software  engineering,  and  indeed  with  most  emerging  technologies.  It  has 
been  the  source  of  great  debate  and  confusion  as  software  engineers  sought  to  define 
exactly  what  it  was  and  how  best  to  use  it.  Indeed,  the  debate  and  research  continues 
unabated  into  what  exactly  constitutes  the  best  way  to  prototype  and  how  to  use  it  most 
effectively.  The  one  point  that  most  software  engineers  agree  upon  is  that  the  larger, 
increasingly  complex  systems  of  today  can  be  more  efficiently  produced  with  the  aid  of 
prototypes.  Thus,  before  looking  too  far  into  the  future  it  would  be  valuable  to  take  a 
look  at  the  past  and  how  we  got  to  where  we  are  today  in  working  with  software 
prototypes. 

A.  WHY  PROTOTYPE  AT  ALL? 

As  computer  languages  came  into  existence,  a  rather  simple  method  of 
developing  software  emerged.  It  was  simply  code  and  fix.  A  programmer  would  sit 
down  and  write  a  program,  run  it  and  then  try  to  fix  the  things  that  didn't  work.  This 
approach  was  sufficient  for  small,  relatively  uncomplicated  programs.  But  just  as 
structured  programming  emerged  to  bring  some  cohesion  to  writing  computer  programs 
and  in  turn  was  replaced  by  the  object  oriented  paradigm,  the  code  and  fix  method  of 
developing  software  systems  was  destined  to  fall  by  the  way  side.  As  systems  became 
more  complicated  and  ever  larger,  one  person  was  no  longer  able  to  do  the  amount  of 
work  required.  The  amount  of  work  was  even  more  than  small  groups  of  software 
engineers  and  programmers  could  handle.  As  more  people  became  involved  in  the 
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process,  it  became  clear  that  a  better  process  was  needed  to  create  software  systems. 
This  led  to  the  waterfall  model  of  software  development. 

1 .  The  Waterfall  Method 

The  waterfall  model,  defined  by  Royce  [ROYC76]  and  refined  by  Boehm 
[BOEH76],  introduced  some  rigor  and  discipline  to  the  development  process.  No  longer 
was  code  written  in  isolation  from  the  bigger  picture  of  what  the  system  should  actually 
do  and  then  tested  to  see  where  it  didn't  work.  Instead,  the  process  was  partitioned  into 
well-defined  development  phases.  Now  there  would  be  a  comprehensive  investigation 
to  determine  the  requirements  of  the  system,  followed  by  design,  implementation  and 
finally  testing  before  a  system  was  released.  In  theory,  this  systematization  of  the 
process  of  producing  software  systems  would  result  in  improved  productivity  and  better 
systems.  To  a  large  degree  it  succeeded  in  achieving  the  desired  results.  However,  as 
systems  continued  to  swell  in  size  and  complexity,  it  became  clear  that  there  existed 
some  serious  shortcomings  with  the  waterfall  method  as  well. 

Foremost  amongst  these  is  the  need  to  establish  the  requirements  for  the 
systems  at  the  beginning  of  the  development  process.  This  is  true  for  several  reasons. 
Customers  may  not  know  exactly  what  they  want  the  final  system  to  really  do  or  they 
may  not  clearly  define  their  needs  to  the  developers.  Also,  requirements  can  change 
due  to  alterations  in  the  environment  that  the  system  will  operate  in,  even  while  the 
system  is  being  developed.  Also,  during  system  development,  requirements  can 
emerge  that  were  overlooked  or  unanticipated  initially.  Whatever  the  reasons  for 
changing,  incomplete  or  missing  requirements,  one  thing  was  for  certain.  Inaccurate 
requirements,  left  unchecked,  propagated  throughout  the  entire  system  and  resulted  in 
software  systems  that  were  late,  over  budget  and  performed  poorly.  Sometimes  entire 
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projects  were  abandoned  as  beyond  salvaging,  as  it  became  clear  that  they  would 
never  perform  as  expected.  As  seen  in  Figures  2.1  and  2.2,  most  of  the  problems 
experienced  by  systems  result  from  inadequacies  with  the  requirements  and  the  later 
these  deficiencies  are  corrected,  the  more  expensive  the  fix  becomes. 


Time  Spent  in  Each  Phase  Source  of  Errors 


Relative  Cost  of  Error  Correction 


Stage 

Relative  Cost  of  Repair 

Requirements 

1 

Design 

5 

Implementation 

10 

Unit  Test 

20 

Acceptance 

50 

Maintenance 

100 

Figure  2.1  The  Importance  of  Early  Requirement  Validation  From  [WOOD92] 
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incorrect  omission  inconsistency  ambiguity  misplaced 
fact  requirement 


Figure  2.2  Types  of  Errors  in  Requirements  From  [WOOD92] 


The  dilemma  confronted  by  software  developers  with  the  waterfall  model  is  aptly 
summed  up  in  a  report  of  the  Defense  Science  Board  Task  Force  on  Military  Software 
[DSB87], 


We  believe  that  users  cannot,  with  any  amount  of  effort  and  wisdom, 
accurately  describe  the  operational  requirements  for  a  substantial 
software  system  without  testing  by  real  operators  in  an  operational 
environment,  and  iteration  on  the  specification.  The  systems  built  today 
are  just  too  complex  for  the  mind  of  man  to  foresee  all  the  ramifications 
purely  by  the  exercise  of  the  analytic  imagination. 
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This  inability  to  completely  anticipate  all  the  requirements  of  system  being  developed 
lead  to  the  creation  of  the  spiral  model  [BOEH86]  for  software  engineering. 

2.  The  Spiral  Model 

The  spiral  model,  shown  in  Figure  2.3,  moved  the  software  development  process 
from  being  documentation  driven  to  one  that  is  risk  driven.  In  other  words,  instead  of 
concentrating  on  completing  the  current  phase  in  the  development  process  before 
moving  on  to  the  next  phase,  you  start  by  identifying  the  areas  with  the  highest  risk  and 
as  you  develop  a  strategy  for  dealing  with  each  one  you  then  tackle  the  next  lower  area 
of  risk.  In  essence  you  have  a  series  of  mini-waterfall  evolutions  but  the  power  of  the 
spiral  method  is  that  the  requirements  do  not  have  to  all  be  known  before  you  start. 
Instead,  you  are  defining  them  as  you  "spiral"  through  iteration  after  iteration,  solving 
the  hardest  part  of  the  system  first  and  working  your  way  to  the  areas  of  relatively  less 
risk.  Prototyping  certainly  is  not  required  to  execute  the  spiral  model  of  development 
but  it  can  dramatically  improve  the  efficiency  of  the  model.  If  the  problem  domain  of  the 
system  being  developed  is  low  risk  and  well  understood,  it  is  possible  to  use  what 
essentially  amounts  to  a  waterfall  method  of  development.  However,  this  is  usually  true 
only  in  uninteresting  or  trivial  systems.  In  most  cases  a  system  is  being  created  for  an 
area  that  is  not  well  understood,  either  by  user  or  developers  or  maybe  even  both. 
Especially  in  the  Department  of  Defense,  this  is  often  the  case  since  many  of  the 
systems  being  developed  are  at  the  cutting  edge  of  technology  or  beyond. 

This  is  when  the  power  of  prototyping  becomes  clear.  By  allowing  developers  to 
present  a  mock-up  of  a  system  early  in  development,  it  is  possible  to  get  user  feedback 
in  a  much  more  timely  manner.  This  capability  makes  the  spiral  method  of  development 
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much  more  effective  since  developers  can  now  produce  prototypes  throughout  the 
iterative  development  process  and  use  the  responses  from  the  ultimate  end  user  to 
continually  refine  the  requirements.  Thus  when  a  final  product  is  delivered,  it  is  much 
more  likely  that  the  system  will  function  as  expected.  This  avoids  a  great  deal  of 
maintenance  effort  and  expense  that  normally  goes  into  modifying  a  delivered  system  in 
order  to  get  it  to  do  what  the  user  really  wanted  in  the  first  place. 


Figure  2.3  Spiral  Model  From  [BOEH86] 
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This  leads  to  consideration  about  what  the  ultimate  role  of  the  prototype  is  within 
the  development  process.  While  there  are  many  variations  and  differing  names,  there 
are  two  basic  purposes  for  prototypes,  both  within  and  outside  the  spiral  model. 
Prototypes  can  be  either  exploratory  or  implementation  oriented.  Exploratory,  also 
referred  to  as  experimental  or  evaluative,  prototypes  are  used  to  better  understand 
some  specific  requirement  or  limitation.  The  intention  is  that  they  will  be  used  and 
discarded  after  providing  the  required  information  and  insight.  Implementation 
prototypes  on  the  other  hand  will  ultimately  become  the  actual  system  being  developed. 
The  biggest  practical  difference  is  simply  how  they  are  created.  An  exploratory 
prototype  which  will  be  "thrown  away"  after  being  used  does  not  have  to  concern  itself 
too  much  with  things  such  as  efficiency,  robustness,  readability,  etc.  It  must  only 
function  in  a  manner  that  allows  the  developers,  and  possibly  the  users,  to  better 
understand  the  question  under  consideration.  The  implementation  oriented  prototype 
must  perform  in  such  a  manner  that  the  code  it  produces  is  of  production  quality. 

3.  Summary  of  Prototyping  Goals 

No  matter  which  approach  to  prototyping  a  development  team  uses,  there  are 
some  general  goals  for  prototyping  that  pertain  to  any  software  system  development 
effort.  Not  every  goal  is  necessarily  applicable  to  every  prototype,  but  they  provide  a 
framework  for  how  prototyping  can  improve  any  development  effort. 

•  Help  systems  engineers,  users  and  developers  to  better  understand  and 
communicate  about  the  environment  and  specific  problem  requirements  and 
to  transfer  design  intent  amongst  themselves; 
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•  Demonstrate  what  is  actually  feasible,  a  specific  system  behavior  or  some 
element  of  the  proposed  system's  performance; 

•  Use  as  a  mechanism  for  getting  the  users  involved  earlier  than  in  traditional 
software  development  processes  thus  potentially  creating  a  more  useful 
system;  and 

•  Get  a  production  version,  of  improved  quality,  completed  in  less  time  than 
with  traditional  methods  without  prototyping. 

B.  THE  EVOLUTION  OF  PROTOTYPING  SYSTEMS 

Exactly  what  constitutes  a  prototype  and  how  you  create  one  has  been  the 
subject  of  much  debate  and  research.  While  there  will  probably  never  be  one  definitive 
prototype  model  that  everyone  accepts,  it  is  illuminating  to  review  a  sampling  of  the 
systems  that  have  been  fielded.  Not  every  system  evaluated  meets  the  definition  of  a 
prototype  but  they  all  have  contributed  to  the  evolution  of  prototyping  systems. 

1 .  Automatic  Code  Generators 

One  of  the  earliest  attempts  at  improving  the  software  development  process  was 
the  idea  of  having  program  source  code  automatically  generated.  Any  productive  and 
useful  prototyping  system  today  will  have  to  incorporate  some  automatic  code 
generation  or  it  will  be  too  cumbersome  to  be  effective.  The  success  of  current 
prototyping  systems  owes  much  to  the  work  done  on  automatic  code  generation. 
However,  automatic  code  generation  by  itself  as  a  stand-alone  development  method 
has  many  shortcomings.  Assuming  that  you  are  confident  that  the  code  being 
generated  is  actually  correct,  there  is  the  question  of  what  it  was  derived  from.  Often, 
automatic  code  generation  amounts  to  not  much  more  than  instantiating  a  template 
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according  to  the  user's  specifications.  The  better  code  generation  systems  such  as 
Graphical  Approach  to  Modeling  and  Building  Interactively  a  Technical  System 
(GAMBITS)  [POWE96]  are  still  restricted  to  a  fairly  narrow  domain.  They  start  small 
using  rigid  models  and  keep  extending  the  systems  being  developed  until  a  useful 
system  is  produced.  However,  useful  prototypes  are  not  part  of  the  process  and  it  is  still 
up  to  the  developers,  users  and  system  analysts  to  ensure  that  correct  requirements  are 
implemented.  Therefore  they  are  limited  outside  their  respective  problem  domain. 

2.  Requirements  Specification  Systems 

The  goal  of  a  requirements  specification  system  is  to  capture  the  complete 
requirements  for  a  system.  Often  poor  communications  result  in  missed,  inaccurate  or 
incomplete  requirements  and  thus  the  specifications  on  which  implementation  will 
ultimately  depend  are  flawed.  A  requirements  specification  system  will  not  produce  a 
prototype  but  the  research  done  in  this  area  has  improved  current  prototyping  systems 
as  well  as  automatic  code  generating  systems  and  executable  specification  languages. 

3.  Executable  Specification  Language 

Executable  specification  languages,  such  as  PAISLey  [ZAVE91]  and  the  Jackson 
Development  System  (JSD)  [ROLL91],  represent  the  operational  approach  to  software 
development.  The  operational  approach  incorporates  three  phases  into  the 
development  process  -  modeling,  specification  and  implementation.  It  closely 
resembles  the  automatic  code  development  paradigm  and  when  done  iteratively  also 
resembles  the  spiral  method  of  development.  The  modeling  though  is  not  a  mock-up  or 
prototype  of  some  part  of  a  system.  Rather  it  is  a  model  of  the  relationships  that  will 
exist  when  the  system  “operates.”  Thus  they  suffer  from  the  same  shortcomings  as 


17. 


automatic  code  generating  systems.  Namely,  the  difficult  task  of  correctly  specifying 
requirements  still  exists  and  the  system  produced  will  be  limited  to  a  relatively  narrow 
problem  domain  such  as  a  data  intensive  business  application  or  database  interactions. 
The  operational  approach  to  software  development  is  not  adequate  for  the  prototyping 
of  more  general  behavior. 

4.  Megaprogramming  Systems 

Megaprogramming  is  the  attempt  to  develop  systems  from  existing  modules. 
Two  examples  are  the  Common  Prototyping  Language  (CPL),  a  Defense  Advanced 
Research  Project  Agency  initiative  that  became  Prototyping  Technology  (Prototech) 
[KIMB92]  and  the  earlier  Rapid  Prototyping  to  Investigate  End-user  Requirements 
(RaPIER)  [WELC86],  Megaprogramming  is  therefore  a  more  sophisticated  form  of  code 
reuse.  As  such,  it  can  be  an  effective  way  to  better  explore  a  relatively  well 
documented  problem  domain  or  one  for  which  work  is  already  underway.  However,  it  is 
limited  as  a  tool  for  probing  new  requirements  though.  It  is  problematic  to  write  the 
code  for  the  modules  to  be  combined  without  first  having  a  good  understanding  of  the 
domain  and  the  requirements  of  the  proposed  system. 

5.  Prototyping  Languages 

As  prototyping  research  gained  momentum,  it  became  clear  to  some  that  the 
ideal  prototyping  system  would  have  at  its  core  a  language  specifically  developed  for 
the  task.  Adapting  existing  languages  invariably  lead  to  shortcomings  and 
compromises  in  the  functionality  of  the  prototyping  system.  PROTEUS  [MILL90]  and 
Durra  [BARB91]  were  two  attempts  to  develop  a  prototyping  language.  PROTEUS  is 
intended  for  prototyping  parallel  and  distributed  environments.  It  contains  set 
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theoretical  notation  with  a  small  set  of  mechanisms  for  controlling  parallel  execution.  It 
relies  on  a  shared  variable  model  of  concurrency  and  focuses  on  regulating 
synchronization  and  communication.  Durra  is  a  task  description  language  for 
developing  distributed  applications.  It  constructs  a  program  by  having  the  user  specify 
the  distributed  application  structure  and  the  resources  allocated  to  each  component. 
The  developer  must  still  code  each  task  and  process  but  templates  exist  for  creating  the 
necessary  interfaces. 

The  limitations  on  languages  such  as  PROTEUS  and  Durra  are  that  they  are 
designed  for  relatively  narrow  domains  and  they  cannot  function  without  some  sort  of 
support  system.  There  is  no  user  interface,  such  as  a  graphical  user  interface  (GUI),  to 
aid  developers.  You  cannot  simply  load  them  into  your  computer  and  start  designing 
prototypes.  So  while  the  idea  of  developing  languages  specifically  for  prototyping  is 
important  for  any  viable  prototyping  system,  it  is  still  just  one  of  several  elements 
needed. 

6.  Computer  Aided  Software  Engineering  (CASE)  Tools 

The  natural  result  of  all  the  research  into  different  aspects  of  prototyping  was  the 
creation  of  CASE  tools  that  combined  many  of  the  disparate  areas  of  research  into  one 
synergistic  mechanism  for  producing  prototypes.  CAPS  and  Proto  [ACOS94]  are  two 
such  systems.  Where  CAPS  focuses  on  applications  in  the  hard  real  time  problem 
domain,  Proto  operates  on  distributed,  parallel  systems.  Proto  provides,  as  does 
CAPS,  a  design  environment  for  the  system  analyst  using  the  System  Specification  and 
Design  Language  (SSDL).  The  design  environment  includes  execution  support,  a  GUI 
and  software  reuse  in  order  to  make  it  a  comprehensive,  efficient  tool  for  developing 


prototypes.  This  total  integration  of  specialized  prototyping  language  and  tailored 
support  environment  is  necessary  to  unlock  the  full  potential  that  prototyping  offers  to 
software  development. 

There  have  been  attempts  to  create  prototyping  systems  without  the  overhead  of 
creating  the  specialized,  integrated  system  described  above.  They  attempt  to  model 
prototypes  using  tools  based  on  such  things  as  Petri  nets  or  relational  databases. 
However,  these  tools  are  cumbersome  and  ultimately  limited  in  their  application. 

7.  Prototyping  Systems  Summary 

The  above  discussion  of  the  history  of  prototyping  systems  is  not  comprehensive 
but  simply  representative  of  the  different  areas  of  research  that  have  contributed  to  the 
considerable  body  of  knowledge  concerning  software  development  with  prototypes.  As 
with  any  technology,  software  development  is  an  ever-changing  entity.  Currently,  the 
iterative  approach  of  the  spiral  method  of  software  development  promises  the  best 
chance  of  creating  software  systems  that  actually  satisfy  the  requirements  specified  by 
the  user.  The  key  to  making  it  effective  for  anything  except  trivial  systems  is  the  ability 
to  rapidly  produce  prototypes  to  examine  proposed  system  behavior.  Many  of  the 
research  efforts  involving  prototyping  have  contributed  to  the  field  and  then  fallen  into 
disuse  as  their  productiveness  reached  practical  limits.  CAPS  has  weathered  the 
turbulence  that  accompanies  any  emerging  technology  and  today  is  not  only  alive  but  a 
vital,  leading  research  tool  in  creating  prototypes  for  supporting  software  system 
development. 
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C.  CAPS  DEVELOPMENT 

As  the  importance  of  prototyping  to  determining  system  behavior  during 
development  became  clear,  it  also  became  obvious  that  to  be  effective  prototypes 
would  have  to  be  created  quickly.  The  requirement  for  a  means  to  rapidly  prototype 
leads  to  the  seemingly  obvious  conclusion  that  a  computer  aided  tool  needed  to  be 
fabricated  for  this  effort  to  succeed.  At  the  time,  the  most  successful  systems  for 
automatically  generating  code  were  focused  in  narrow  problem  domains  and  relied 
upon  templates  or  generic  solutions.  In  order  to  achieve  the  type  of  powerful, 
automated  prototyping  system  envisioned,  a  computer  language  would  have  to  be 
design  specifically  for  this  purpose.  That  language  was  Prototype  System  Description 
Language  (PSDL)  [LUQI88b].  The  objective  of  PSDL  was  to  mechanically  create 
documents  that  could  be  processed  and  executed  at  the  specification  level.  In  other 
words,  PSDL  was  designed  to  be  an  executable  prototyping  language  at  the 
specification  or  design  level. 

As  CAPS  is  built  around  PSDL,  PSDL  provides  more  than  simply  an  executable 
prototyping  language.  Queries  to  search  the  database  repository  of  reusable  software 
components  are  based  on  PSDL.  CAPS  incorporates  a  GUI  with  which  the  system 
designer  can  graphically  represent  the  desired  requirements.  CAPS  will  transform  this 
graphical  description  into  PSDL.  Once  in  PSDL,  the  Ada  components  can  be  generated 
and  bound  together.  After  compilation,  CAPS  provides  the  facilities  for  graphically 
displaying  the  prototype.  This  allows  system  behavior  to  be  evaluated  and  the 
necessary  changes  made  to  requirements  in  a  timely  manner.  Thus,  CAPS  supports  an 
iterative  approach  to  software  system  development. 
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D.  PROTOTYPING  RISKS 

It  would  be  unfair  and  unrealistic  to  think  that  prototyping  does  not  incur  some 
risks.  It  is  certainly  not  the  fabled  silver  bullet  but  simply  a  means  for  increasing  the 
efficiency  and  accuracy  of  the  system  development  process.  It  is  important  to 
understand  the  shortcomings  of  prototyping  in  order  to  take  full  advantage  of  its 
tremendous  potential.  Some  of  the  risks  associated  with  prototyping  are: 

•  overly  enthusiastic  developers  who  want  to  continually  iterate  and  evolve  a  prototype 
by  adding  additional  functionality  beyond  that  which  was  originally  being 
investigated; 

•  classification  of  a  prototyping  effort  as  rapid  can  lead  managers  to  think  that  this 
area  can  easily  absorb  budget  cuts  and  shortcuts  without  affecting  the  product; 

•  the  temptation  to  substitute  a  prototype  that  appears  to  work  for  a  fully  documented 
and  tested  final  product;  and 

•  a  misunderstanding  about  the  purpose  of  prototyping  in  the  development  process  by 
users  or  customers  can  lead  to  acrimony  with  the  development  team  and 
compromise  the  close  working  relationship  that  produces  the  best  results. 

E.  THE  FUTURE 

CAPS  today  is  an  energetic,  productive  research  effort  into  the  use  of  rapid 
prototyping  for  software  development.  Its  contributions  are  many  and  continue  to 
appear  at  an  impressive  rate.  Distributing  CAPS  itself  certainly  will  ensure  its  lasting 
viability.  Perhaps,  however,  even  more  is  needed  if  CAPS  is  to  remain  at  the  leading 
edge  of  this  research  field  and  eventually  become  a  mature  product  widely  used 
throughout  commercial  software  development.  Focusing  only  on  the  domain  of  hard 
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real  time  applications  is  certainly  becoming  a  limitation.  The  not  too  distant  future, 
actually  beginning  to  appear  already,  will  see  the  emergence  of  applications  that 
combine  the  requirements  of  hard  real  time  constraints  with  concurrent  operation  across 
distributed  networks  that  are  growing  seemingly  without  bound.  Failure  to  support  such 
applications  risks  being  left  on  the  sidelines  or  marginalized  into  some  software 
development  niche. 
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III.  REQUIREMENTS  ANALYSIS  FOR  DEPLOYING  CAPS  IN  A  DISTRIBUTED 

ENVIRONMENT 

Fielding  a  sound,  usable  system  doesn't  occur  by  happenstance  or  even  simply 
hard  work.  It  is  the  result  of  a  great  deal  of  careful  analysis  and  planning  long  before 
any  implementation  ever  begins.  If  the  requirements  are  not  properly  detailed,  you  can 
easily  end  up  with  a  system  that  does  something  very  well  but  does  not  do  what  the 
customer  wanted.  If  the  architecture  is  not  precise,  the  development  can  spin  out  of 
control  during  implementation  as  each  ambiguity  results  in  a  workaround.  These 
workarounds  and  individual  interpretations  of  what  the  designers  meant  compound  on 
each  other  until  system  cohesion  begins  to  suffer.  The  goal  of  this  chapter  is  to 
fabricate  the  foundation  of  a  clear  and  logical  requirements  analysis. 

A.  CREATING  A  WELL  DESIGNED  SYSTEM 

The  goal  of  any  system  design  should  be  the  production  of  a  system  that  is 
effective,  efficient,  robust  and  maintainable.  Currently,  the  best  way  to  achieve  that  goal 
is  through  rigorously  applying  the  techniques  of  object-oriented  analysis  and  design. 
Modeling  is  the  underpinning  that  makes  object-oriented  analysis  and  design 
successful.  Through  modeling,  everyone  involved  in  the  development  process,  from 
stakeholders  to  testers  to  managers,  can  come  to  a  clear  understanding  and  agreement 
about  how  the  system  will  ultimately  perform.  Today,  the  state  of  the  practice  for 
modeling  is  the  Unified  Modeling  Language  (UML). 

1.  UML  Overview 

UML  was  designed  to  be  as  flexible  as  possible.  In  fact,  it  can  be  applied  to 
almost  any  process,  not  just  software  design.  It  is  meant  to  simply  be  a  tool  in  the 
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software  engineers  toolkit.  However,  it  can  be  a  very  powerful  tool.  Utilized  to  its 
fullest,  UML  can  be  integrated  into  a  project  from  the  outset  while  searching  for  the 
complete  requirements  and  used  through  designing  the  architecture,  implementing  the 
desired  system  and  finally  testing  the  production  code.  It  is  a  language  that  focuses  on 
the  conceptual  and  physical  nature  of  a  system.  Thus  it  can  be  used  to  build  the 
blueprints  for  a  software  system.  Specifically,  UML  is  designed  for  the  visualizing, 
specifying,  constructing  and  documenting  of  software  artifacts  [BOOC99]. 

a.  Visualizing 

UML  helps  a  system  developer  record  and  present  to  others  the  ideas 
he/she  has.  This  can  be  a  tremendously  powerful  way  of  fostering  communication 
between  the  stakeholders,  developers,  project  managers,  users  and  any  other 
interested  party. 

b.  Specifying 

UML  capitalizes  on  the  improved  communications  by  allowing  the 
developer,  using  his/her  enhanced  understanding  of  the  system  objectives,  to  build 
models  that  are  precise,  unambiguous  and  complete. 

c.  Constructing 

The  developer  can  directly  connect  the  models  to  various  programming 
languages.  Thus,  it  is  possible  to  generate  programming  source  code  in  languages 
such  as  Ada,  C++  and  Java. 
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d.  Documenting 

Many  artifacts  will  be  produced  during  a  development  cycle  while  using 
UML.  These  can  form  the  basis  of  a  thorough,  persistent  documentation  effort. 

2.  Using  UML  to  Redesign  CAPS 

As  stated  before,  UML  is  only  a  tool  in  the  software  design  process.  It  is  not  a 
set-in-stone,  explicitly  detailed  process.  Rather,  it  is  up  to  the  developer  to  decide  how 
to  best  employ  UML.  UML  gives  you  the  structural  pieces  for  creating  a  solid  design  but 
there  are  many  ways  to  actually  put  the  pieces  together.  The  nature  of  UML  though 
lends  itself  to  best  supporting  a  spiral  or  incremental  development  approach. 

We  view  this  work  as  the  beginning  effort  in  redesigning  CAPS  for  the  future. 
Our  goal  is  to  first  establish  the  requirements  for  an  improved,  distributed  CAPS.  The 
requirements  are  just  a  description  of  the  needs  and  desires  for  what  a  system  should 
do  when  deployed.  Although  this  is  a  simple  idea,  it  is  critically  important.  If  the 
requirements  are  not  clearly  and  accurately  defined,  all  that  comes  afterwards  in  the 
development  process  can  be  easily  compromised.  We  have  chosen  to  work  with  the 
UML  model  in  this  effort  because  we  believe  it  can  be  easily  extended  in  follow  on 
theses. 

Our  methodology  in  defining  the  requirements  for  the  next  CAPS  will  be  to  first 
determine  the  necessary  system  functions  and  attributes.  Next,  we  will  promote  a 
better  understanding  of  the  processes  involved  with  the  application  of  use  cases. 
Finally,  we  will  complete  the  analysis  with  a  proposed  conceptual  diagram.  We  strongly 


believe  that  this  will  be  the  key  to  a  successful  design  and  implementation  phase  in  the 
future. 

B.  METHODOLOGY  SPECIFICS 

The  methodology  we  used  for  determining  the  requirements  is  detailed  below. 

1.  System  Functions 

Simply  stated,  the  system  functions  are  what  the  system  should  actually  do  in  the 
real  world.  System  attributes,  on  the  other  hand,  are  non-functional  system  qualities. 
System  functions  can  placed  in  one  of  two  categories  -  evident  or  hidden.  The  user  is 
aware  when  evident  functions  are  being  performed.  The  performance  of  hidden 
functions  is  not  visible  to  the  user.  Often,  underlying  technical  services,  such  as  saving 
information  to  a  persistent  storage  mechanism,  are  hidden. 

Constraints  and  details  influence  system  attributes.  These  also  fall  into  two 
categories  -  must  and  want.  In  reality,  if  a  constraint  is  truly  real,  it  should  be  classified 
as  only  must.  Thus  it  is  only  attribute  details  that  are  characterized  as  must  or  want. 

2.  Use  Cases 

Simply  put,  use  cases  are  a  narrative  description  of  domain  processes  that 
highlight  the  interactions  between  the  system  being  designed  and  external  agents. 
External  agents  can  be  such  things  as  people,  other  systems,  computers  or  processes. 
According  to  the  creators  of  the  UML,  a  use  case  is  a  description  of  a  set  of  sequence 
actions  that  a  system  performs  that  yields  an  observable  result  to  a  particular  actor.  A 
use  case  is  used  to  structure  the  behavioral  things  in  a  model.  [BOOC99] 

Capturing  the  intended  behavior  of  the  system  being  designed  is  the  goal  of  a 
use  case.  This  facilitates  easier,  more  complete  communication  end  users,  domain 
experts  and  developers.  Use  cases  help  draw  attention  to  high  risk  areas  sooner  by 
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fostering  clearer  investigations  of  domain  processes.  Any  discussion  of  implementation 
should  be  avoided  in  use  cases.  The  goal  is  to  discuss  what  should  be  done,  not  how 
to  do  it.  However,  use  cases  can  be  utilized  to  corroborate  about  a  proposed 
architecture.  Two  types  of  use  case  will  be  of  interest  in  reengineering  CAPS.  First, 
high-level  use  cases  will  demonstrate  all  the  interactions  between  actors  and  the 
system  in  very  general  terms.  It  provides  a  broad-brush  overview  of  what  the  system 
should  accomplish.  The  more  interesting  or  critical  use  cases  will  be  further  detailed  in 
expanded  use  cases.  Finally,  a  use  case  diagram  will  link  the  narrative  use  cases  to 
the  UML. 

Use  cases  can  help  validate  the  rules  of  interactions  between  actors  and  actors 
or  actors  and  the  system.  Exploration  of  the  variations  on  scenarios  can  result  from  use 
case  discussions.  Often,  nontrivial  scenarios  will  have  alternate  paths  of  action 
revealed  during  such  discussions  and  possibly  one  of  them  will  be  an  improvement  on 
the  original  idea.  The  crucial  characteristic  is  work  should  always  be  accomplished.  In 
other  words,  something  should  be  done  that's  of  value  to  an  actor. 

Lastly,  use  cases  can  form  the  basis  for  developing  test  plans.  As  use  cases 
are  modified,  the  changes  needed  in  the  test  plan  are  clearly  established.  A  use  case 
gives  the  test  developer  a  straightforward,  plain  language  narrative  of  what  is  supposed 
to  happen.  As  use  cases  can  be  easily  extended  and  more  detailed  throughout  the 
development  process,  they  make  it  possible  to  easily  support  a  spiral  or  incremental 
development  methodology. 

3.  Conceptual  Model 

The  conceptual  model  illustrates  meaningful  concepts,  i.e.  .objects,  in  a  problem 
domain.  Decomposition  by  concepts  supports  object  oriented  analysis  whereas 
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structural  analysis  is  decomposition  by  processes  or  functions.  Developing  a 
comprehensive  set  of  objects  is  the  key  to  successful  object  oriented  analysis.  A  static 
structures  diagram  expresses  the  conceptual  model  in  UML.  The  concepts  are 
identified  and  their  attributes  delineated  as  well  as  their  associations  with  other 
concepts.  There  are  no  methods  listed  though.  This  construction  serves  to  emphasize 
the  fact  that  concepts  in  the  conceptual  model  are  representing  real  world  entities  and 
not  software  components.  The  concepts  will  be  derived  from  the  use  cases  and 
functional  requirements. 

C.  REQUIREMENTS  ANALYSIS  RESULTS 

The  results  of  the  initial  requirements  analysis  for  reengineering  CAPS  are 
detailed  below. 

1.  Functional  Requirements 

The  functional  requirements  for  a  reengineered  CAPS  are  listed  in  Tables  3.1  - 
3.7  grouped  by  various  user  inputs,  system  management,  network  support  and  project 
management 


Table  3.1  User  Input  Functions-Requirements  Analysis 


Ref# 

Function 

Function 

Category 

Attribute 

Details  and 
Constraints 

Detail 

Category 

m 

Record  stakeholder 
comments 

evident 

interface 

metaphor 

form  driven  text 
format 

must 

R1.2 

Record  user  comments 

evident 

interface 

metaphor 

form  driven  text 
format 

must 

R1.3 

Record  requirements  for 
the  system  being 
developed 

evident 

interface 

metaphor 

form  driven  text 
format 

must 
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Table  3.2  User  Input  Functions-System  Modeling/Specification 


Ref# 

Function 

Function 

Category 

Attribute 

Details  and 
Constraints 

Detail 

Category 

R1.4 

Model  hard  real  time 
systems 

evident 

interface 

metaphor 

graphical  user 
interface  for  flow 
diagram  and  form 
metaphor  input  for 
hard  real  time 
constraints 

must 

R1.5 

Model  distributed 
systems 

evident 

interface 

metaphor 

graphical  user 
interface  for  flow 
diagram  and  form 
metaphor  input  for 
distributed  system 
constraints 

must 

R1.6 

Model  concurrent 
systems 

evident 

interface 

metaphor 

graphical  user 
interface  for  flow 
diagram  and  form 
metaphor  input  for 
concurrent  system 
constraints 

must 

R1.7 

Model  any  combination 
of  hard  real  time, 
concurrent  or  distributed 
system 

evident 

interface 

metaphor 

graphical  user 
interface  for  flow 
diagram  and  form 
metaphor  input  for 
hard  real  time, 
concurrent  and/or 
distributed  system 
constraints 

must 

Table  3.3  User  Input  Functions-Prototype  Development 


Ref# 

Function 

Function 

Category 

Attribute 

Details  and 

Constraints 

Detail 

Category 

R1.8 

Translate  PSDL  code 
into  3rd  generation  object 
oriented  language  source 
code 

evident 

response  time 

source  code  will  be 
generated  in  less  than 

2  minutes 

want 

R1.9 

Edit  prototype  source 
code 

evident 

response  time 

source  code  will  be 
available  in  less  than 

10  seconds 

want 

R1.10 

Compile  software 
modules  in  a  prototype 

evident 

response  time 

object  code  will  be 
generated  in  less  than 

2  minutes 

want 

Rl.ll 

Link  compiled  modules 
in  a  prototype 

evident 

response  time 

linking  will  be 
completed  in  less  than 

2  minutes 

want 

R1.12 

Execute  prototype 

evident 

platform 

prototype  must  be  able 
to  execute  on  UNIX 
and 

Windows95/98/NT 

must 
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Table  3.3  User  Input  Functions-Prototype  Development  (continued) 


R1.13 

Statically  check  hard 
real-time  timing 
constraints  for  system 
prototype 

evident 

response  time 

complete  timing 
validation  in  less  than 

1  minute 

want 

R1.14 

Dynamically  check  hard 
real-time  timing 
constraints  for  system 
prototype 

evident 

fault  tolerance 

identify  violations  of 
timing  constraints 
while  executing 

must 

R1.15 

Dynamically  report 
network  collisions  for 
distributed  system  * 
prototype 

evident 

fault  tolerance 

identify  details  of 
simulated  network 
collisions  while 
executing 

must 

R1.16 

Dynamically  record 
synchronization  details 
for  system  prototype 

evident 

fault  tolerance 

identify  details  of 
simulated  network 
timing  while  executing 

must 

R1.17 

Save  component  to  local 
persistent  storage 

hidden 

response  time 

save  should  execute  in 
less  than  1  minute 

want 

R1.18 

hidden 

response  time 

save  should  execute  in 
less  than  1  minute 

want 

R1.19 

Commit  component  to 
persistent  storage 

hidden 

response  time 

commit  should 
execute  in  less  than  1 
minute 

want 

R1.20 

Commit  project  to 
persistent  storage 

hidden 

response  time 

commit  should 
execute  in  less  than  1 
minute 

want 

Table  3.4  User  Input  Functions-Reuse 


Ref# 

Function 

Function 

Category 

Attribute 

Details  and 
Constraints 

Detail 

Category 

R1.21 

Select  software  module 
from  reuse  database 

evident 

shared 

component 

access 

provide  matches  in 
less  than  1  minutes 

want 

R1.22 

Save  software  modules 
to  reuse  database 

hidden 

shared 

component 

access 

provide  Software 
Librarian  controls  for 
reuse  database 

must 

R1.23 

Delete  software  modules 
from  reuse  database 

hidden 

shared 

component 

access 

provide  Software 
Librarian  controls  for 
reuse  database 

must 
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Table  3.5  System  Administration 


Ref# 

Function 

Function 

Category 

Attribute 

Details  and 
Constraints 

Detail 

Category 

R2.1 

Allow  Software 

Librarian  to  add  new 
users  to  access  list  for 
software  component 
database 

hidden 

scalability 

allow  enough  users  to 
support  very  large 
system  development 

must 

R2.2 

Allow  Software 

Librarian  to  delete  new 
users  from  access  list  for 
software  component 
database 

hidden 

scalability 

allow  enough  users  to 
support  very  large 
system  development 

must 

R2.3 

Allow  project  manager 
to  grant  file  access  to 
specific  users 

hidden 

security 

only  allow  authorized 
user  to  access  a  project 

must 

Allow  project  manager 
to  revoke  file  access  to 
specific  users 

hidden 

security 

only  allow  authorized 
user  to  access  a  project 

must 

R2.5 

Recover  from  a  local 
system  failure 

hidden 

fault  tolerance 

Restore  system  back  to 
a  safe  state  after  a 
local  failure 

must 

■ 

Recover  from  a  global 
application  failure 

hidden 

fault  tolerance 

Restore  system  back  to 
a  safe  state  after 
system  wide 
application  failure 

must 

R2.7 

Recover  from  a  local 
application  failure 

hidden 

fault  tolerance 

Restore  system  back  to 
a  safe  state  after  a 
local  application 
failure 

must 

Table  3.6  Network  Support 


^nm 

Function 

Function 

Category 

Attribute 

Details  and 
Constraints 

Detail 

Category 

R3.1 

Transmit  module  to  a 
remote  site 

hidden 

shared 

component 

access 

securely  get  work 
from  one  site  to 
another  site 

must 

R3.2 

Download  module  from 
a  remote  site 

hidden 

shared 

component 

access 

securely  get  work 
from  one  site  to 
another  site 

must 

Detect  errors  in 
transmission  of  modules 

hidden 

fault  tolerance 

ensure  integrity  of 
modules  moving  over 
network 

must 

Generate  alert  for 
detected  errors  in 
transmission 

hidden 

fault  tolerance 

ensure  integrity  of 
modules  moving  over 
network 

must 
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Table  3.6  Network  Support  (continued) 


R3.5 

Recover  from  a  global 
system  failure 

hidden 

fault  tolerance 

Restore  system  back  to 
a  safe  state  after 
system  wide  failure 

must 

R3.6 

Acknowledge  error-free 
transmission  of  module 

Hidden 

fault  tolerance 

ensure  integrity  of 
modules  moving  over 
network 

must 

Table  3.7  Project  Management 


Ref# 

Function 

Function 

Category 

Attribute 

Details  and 

Constraints 

Detail 

Category 

R4.1 

User  must  log  in 
securely  in  order  to  use 
system 

evident 

response  time 

less  than  10  seconds 

want 

R4.2 

Create  new  project 

evident 

response  time 

less  than  5  seconds 

want 

R4.3 

Load  existing  project 

evident 

response  time 

less  than  10  seconds 

want 

R4.4 

Record  version  for  all 
software  artifacts 

hidden 

ease  of  use 

system  must  track  and 
record  order  in  which 
artifacts  entered 

must 

R4.5 

Add  component  to 
project 

evident 

response  time 

component  should 
included  in  project  in 
less  than  1  minute 

want 

R4.6 

Merge  components  from 
different  sources  into 
one  component 

evident 

ease  of  use 

system  must 
automatically  merge 
components,  tracking 
versions 

must 

R4.7 

Merge  components  from 
different  sources  into 
one  project 

evident 

ease  of  use 

system  must 
automatically  merge 
components,  tracking 
versions 

must 

R4.8 

Alert  project  manager  to 
conflicts  during  merge 
operations 

evident 

version  control 

system  must  identify 
version  conflicts  and 
inform  the  project 
manager 

must 

response  time 

Project  manager 
should  be  alerted  in 
less  than  2  minutes 

want 
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2.  High-level  Use  Cases 

The  high-level  use  case  are  detailed  below. 


Use  Case: 

Actors: 

Type: 

Overview: 

Cross  Reference: 


U1.  Start-up 
System  Administrator 
primary 

System  Administrator  logs  onto  host  system  and  initiates  CAPS. 
Functions:  R2.5,  R2.6,  R2.7,  R3.5 


Use  Case: 
Actors: 

Type: 

Overview: 


Cross  Reference: 


U2.  Log  in 
User 

primary 

After  CAPS  is  initiated,  a  user  must  log  into  CAPS  in  order  to 
determine  what  project  and  reuse  database  privileges  the  user 
owns. 

Functions:  R2.3,  R4.1 


Use  Case: 
Actors: 
Type: 
Overview: 


Cross  Reference: 


U3.  Open  project 

User 

primary 

After  logging  into  CAPS,  user  can  either  open  a  new  project  or 
select  an  existing  project  and  open  it,  if  he  has  the  proper 
authorization  from  the  project  manager. 

Functions:  R2.3,  R4.2,  R4.3 


35 


Use  Case: 
Actors: 
Type: 
Overview: 


Cross  Reference: 

Use  Case: 

Actors: 

Type: 

Overview: 


Cross  Reference: 


U4.  Modify  prototype 

User 

primary 

After  opening  a  project,  the  user  will  be  able  to  make  changes  to 
the  graphical  interface  of  the  control  flow  diagram  or  to  the  text 
boxes  associated  with  either  objects  or  data  streams  in  the 
diagram.  These  changes  will  be  automatically  reflected  in  the 
PSDL  code.  The  user  can  record  user  comments,  stakeholder 
comments  and  requirements  for  the  system  being  prototyped. 
Additionally,  the  user  can  directly  access  the  PSDL  code  and 
change  it  manually. 

Functions:  R1.1,  R1.2,  R1.3,  R1.4,  R1.5,  R1.6,  R1.7,  R1.21,  R4.4, 
R4.5 


U5.  Retrieve  component  from  reuse  database 

User 

primary 

The  user  accesses  the  reuse  database  and  inputs  search 
parameters.  CAPS  responds  with  no  match,  unique  match  or  a  list 
of  possible  matches.  CAPS  generates  an  alert  if  there  is  an  error  in 
transmission  and  an  acknowledgement  if  the  transfer  is  successful. 
Functions:  R1.21,  R3.2,  R3.4,  R3.6 
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Use  Case: 


U6.  Save 


Actors: 

Type: 

Overview: 

Cross  Reference: 

Use  Case: 

Actors: 

Type: 

Overview: 

Cross  Reference: 

Use  Case: 

Actors: 

Type: 

Overview: 


Cross  Reference: 


User 

primary 

User  has  opened  a  project  or  component  and  now  saves  it  to  local 
persistent  storage. 

Functions:  R1.17,  R1.18 

U7.  Modify  GUI  for  displaying  prototype  execution 

User 

primary 

User  selects  and  then  edits  the  files  that  provide  functionality  for 
displaying  prototype  execution. 

Functions:  R1.4,  R1.5,  R1.6,  R1.7,  R1.8,  R1.9 

U8.  Generate  executable  prototype 

User 

primary 

The  user  translates  the  prototype  in  order  to  create  source  code  in 
an  implementation  language  from  the  PSDL  and  link  it.  The  user 
will  then  verify  through  CAPS  that  all  static  hard  real  time 
constraints  are  met.  The  user  will  then  compile  the  prototype 
source  code. 

Functions:  R1.9,  R1.10,  R1.11 
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Use  Case: 
Actors: 
Type: 
Overview: 


Cross  Reference: 

Use  Case: 

Actors: 

Type: 

Overview: 


U9.  Execute  the  prototype 

User 

primary 

The  user  will  execute  the  prototype.  As  the  user  test  the  prototype 
functionality,  CAPS  will  verify  that  all  dynamic  hard  real  time, 
concurrency  and  network  constraints  are  met.  CAPS  will  allow  the 
user  to  record  stakeholder  and/or  user  comments. 

Functions:  R1.1,  R1.2,  R1.3,  R1.12,  R1.13,  R1.14,  R1.15,  R1.16 

U10.  Manage  project  changes 
User,  Project  Manager 
primary 

User  (possibly  more  than  one)  will  submit  module(s)  to  the  Project 
Manager  for  incorporation  into  the  project  prototype.  The  user  may 
elect  to  return  the  entire  prototype  after  making  changes  to  only 
some  of  the  modules.  In  this  case  the  Project  Manager  must 
identify  which  modules  are  changed  or  new.  If  the  module  does  not 
already  exist  in  the  project  database,  the  Project  Manager  will 
merge  the  submitted  module(s)  into  one  module,  resolving  any 
conflicts.  CAPS  will  assign  and  track  a  version  number  and  insert 
the  module  into  the  project  database,  making  ties  to  all  other 
modules  that  may  exist  in  the  project  database.  If  the  module 
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Cross  Reference: 

Use  Case: 

Actors: 

Type: 

Overview: 


Cross  Reference: 


previously  existed  in  the  project  database,  the  Project  Manager  will 
merge  all  submitted  modules  with  the  existing  one,  resolving  any 
conflicts.  CAPS  will  update  the  version  number.  If  an  existing 
module  is  submitted  to  the  Project  Manager,  CAPS  will  verify  that 
all  other  modules  that  it  depends  on  are  the  most  up  to  date 
version.  CAPS  will  generate  an  alert  if  there  is  an  error  in 
transmitting  a  module  and  an  acknowledgement  if  there  is  no  error. 
Functions:  R1.19,  R1.20,  R3.1,  R3.3,  R3.4,  R3.6,  R4.3,  R4.4,  R4.6, 
R4.7,  R4.8 

U1 1 .  Manage  reuse  database  changes 

User,  Software  Librarian 

primary 

User  submits  a  new  module,  or  an  existing  one  that  was  modified, 
to  the  Software  Librarian.  When  the  Software  Librarian  accepts  the 
module  for  inclusion  in  the  reuse  database,  a  version  control 
number  is  assigned  or  updated  as  necessary  and  the  module  is 
saved  to  the  reuse  library.  If  the  module  was  an  update  of  an 
existing  one,  all  users  of  the  old  version  are  alerted.  The  Software 
Librarian  can  also  delete  modules. 

Functions:  R1.22,  R1.23,  R3.1,  R3.3,  R3.4,  R3.6 
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Use  Case: 


Actors: 

Type: 

Overview: 

Cross  Reference: 

Use  Case: 

Actors: 

Type: 

Overview: 

Cross  Reference: 

Use  Case: 

Actors: 

Type: 

Overview: 

Cross  Reference: 

Use  Case: 

Actors: 

Type: 


U12.  Add  user  to  project  access 

Project  Manager 

secondary 

The  Project  Manager  grants  a  user  access  to  a  specific  project. 
Functions:  R2. 3 

U13.  Delete  user  from  project  access 

Project  Manager 

secondary 

The  Project  Manager  deletes  a  user's  access  to  a  specific  project. 
Functions:  R2.4 

U14.  Add  user  to  the  reuse  database 

Software  Librarian 

secondary 

Upon  receiving  request,  Software  Librarian  will  add  user  to  the 
reuse  database  access  list. 

Functions:  R2.1 

U15.  Delete  user  from  the  reuse  database 

Software  Librarian 

secondary 
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Overview:  Upon  receiving  request,  Software  Librarian  will  delete  user  from  the 

reuse  database  access  list. 

Cross  Reference:  Functions:  R2.2 

Use  Case:  U16.  Exit  project 

Actors:  User 

Type:  primary 

Overview:  The  user  exits  the  current  project.  If  unsaved  data  exist,  CAPS  will 

ask  the  user  if  they  want  to  save  the  data  before  exiting  the  project. 
Cross  Reference:  Functions:  R1.18.  R1.20 

Use  Case:  U17.  Log  off 

Actors:  User 

Type:  primary 

Overview:  User  request  to  log  off  from  the  current  session  of  CAPS.  If 

unsaved  data  exist,  CAPS  will  ask  the  user  if  they  want  to  save  the 
data  before  logging  the  user  off  CAPS  and  quitting  the  current 
session  of  CAPS. 

Cross  Reference:  Functions:  R1.18,  R1.20 

3.  Expanded  Uses  Cases 

The  expanded  use  cases  are  detailed  in  Appendix  A.  They  are:  U3.  Open 
project:  U4.  Modify  prototype;  U5.  Retrieve  component  from  reuse  database;  U7.  Modify 
GUI  for  displaying  prototype  execution;  U8.  Generate  executable  prototype; 
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U9.  Execute  the  prototype;  U10.  Manage  project  changes;  U11.  Manage  reuse 
database  changes. 

4.  Conceptual  Diagrams 

The  list  of  components  used  in  the  conceptual  diagrams  is  shown  below  in  Table 
3.8  and  the  detailed  subsections  are  shown  in  figures  3.1  through  3.5.  The  complete 
descriptions  of  the  relations  and  concepts  are  included  in  the  detailed  views. 


Table  3.8  Conceptual  Diagram  Components 


Access  List 

Alert 

CAPS 

CAPS  Graphical  Interface 

CAPS  Menu 

Comment 

Compiler 

Component 

Constraint 

Editor 

Error 

Executable  Code 

GUI  Builder 

Host  System 

List  of  Possible  Matches 

Network 

Persistent  Storage 

Project 

Project  Database 

Project  Manager 

Prototype 

Prototype  GUI 

PSDL  Code 

PSDL  Data  Stream 

PSDL  Diagram 

PSDL  Object 

Query 

Remote  Site 

Requirement 
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Table  3.8  Conceptual  Diagram  Components  (continued) 

Reuse  Library _ 

Reuse  Library  Search _ 

Scheduler _ 

Search  Parameters _ 

Software  Librarian _ 

Source  Code _ 

Stakeholder _ 

System  being  Designed _ 

System  Parameters _ 

Text  Box _ 

Translator _ 

User _ _ 

Work  Station 
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Figure  3.1  Conceptual  Diagram  -  Network  Support 
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contains 


Figure  3.2  Conceptual  Diagram  -  Reuse  Support 
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controls  uses 


SOFTWARE 

LIBRARIAN 


NAME 

PASSWORD 


Figure  3.3  Conceptual  Diagram  -  Management  Support 
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Figure  3.4  Conceptual  Diagram  -  Execution 
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Figure  3.5  Conceptual  Diagram  -  User  Inputs 
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IV.  ARCHITECTURAL  DESIGN  FOR  CAPS  IN  A  DISTRIBUTED  NETWORK 

The  choices  for  how  to  design  the  architecture  for  a  distributed  CAPS  fall  along 
an  unbroken  continuum.  At  one  end  you  have  dumb  client  machines  and  a  super  smart 
server  that  does  all  the  work  and  returns  the  results  to  the  clients  for  display  to  the  user. 
On  the  other  end  of  the  spectrum  you  have  a  set  up  that  resembles  most  Local  Area 
Networks  (LAN)  where  the  server  simply  provides  a  service,  such  as  file  downloads, 
and  the  client  machines  do  all  the  work.  The  first  is  highly  centralized  and  the  second 
highly  decentralized.  We  believe  that  the  most  optimum  solution  is  a  client-server 
architecture  that  falls  in-between  the  extremes  of  this  continuum.  The  rapid  growth  in 
the  amount  of  bandwidth  available  on  all  kinds  of  networks,  including  the  Internet,  make 
sophisticated  client-server  architectures  very  feasible. 

A.  DEFINING  THE  CAPS  CLIENT-SERVER  ARCHITECTURE 

Any  design  must  take  advantage  of  the  increasing  power  of  today’s  desktop 
personal  computers  (PC).  By  moving  a  significant  load  from  the  server  to  the  client 
machines,  you  can  dramatically  improve  scalability  by  reducing  the  amount  of  work  the 
server  must  do  and  the  quantity  of  data  it  must  send  to  client  machines.  However,  the 
implementation  of  this  client-server  architecture  should  not  be  limited  to  just  one  type  of 
PC.  Indeed,  client  machines  do  not  necessarily  have  to  even  be  a  PC.  They  could,  for 
instance,  be  a  UNIX  workstation.  This  diversity  reflects  the  reality  of  most  networks 
today.  They  are  becoming  more  and  more  heterogeneous.  The  internet  is  the  ultimate 
example  of  this  heterogeneity  but  by  no  means  the  only  example.  The  Heterogeneous 
Systems  Integrator  (HSI),  which  contains  a  PSDL  graphical  editor,  written  by  llker 
Duranlioglu  [DURA99]  provides  an  important  first  step  in  creating  a  powerful  CAPS 
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client  that  any  truly  successful  distributed  CAPS  design  will  require.  The  HSI  is  an  all 
Java  implementation. 

1 .  A  Three  Tier  Client-Server  Design 

A  robust  three  tier  design  is  the  preferred  way  to  implement  a  distributed  CAPS 
in  the  client-server  model.  The  three  tier  design  offers  several  advantages  over  the 
older  two  tier  model.  First,  it  more  closely  resembles  the  object  oriented  paradigm 
practiced  today.  You  can  encapsulate  the  functionality  of  the  client-server  design  easily 
in  a  three  tiered  model  and  as  long  as  the  interfaces  between  each  tier  remain 
unchanged,  you  can  update  the  separate  parts  independently.  The  three  tiers  in  a 
distributed  CAPS  are  the  client  side,  represented  by  the  HSI,  the  communication  server 
that  communicates  with  multiple  clients  over  a  network  and  the  ‘back  end’  programs  that 
do  the  actual  work  requested  by  the  clients  on  the  computational  server.  Additionally, 
by  carefully  allocating  responsibilities  in  the  design  you  can  noticeably  improve 
performance  and  latency  by  ensuring  good  load  balancing.  Thus,  no  particular  node 
becomes  a  bottleneck. 

2.  Component  Responsibilities 

One  of  the  first  questions  to  resolve  in  designing  a  distributed  system,  is  who  will 
be  responsible  for  maintaining  state  information.  This  can  be  quite  complicated  and 
introduce  large  inefficiencies  if  it  is  done  at  one  central  location,  i.e.,  on  the  server  side 
of  the  network.  Thus,  we  decided  that  the  best  approach  was  for  each  client  to  maintain 
their  own  state  information.  Fortunately,  this  does  not  introduce  very  much  additional 
complexity  to  the  HSI  already  written.  The  HSI  already  manages  threads  that  are 
created  by  opening  prototypes  and  editors.  It  is  a  relatively  simple  matter  for  the  HSI  to 
include  state  information  whenever  it  invokes  services  from  the  server.  This  allows  the 
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server  to  focus  on  facilitating  requests  from  various  clients.  If  the  server 
asynchronously  passes  client  requests  off  to  ‘back  end’  for  processing,  then  it  can 
continue  to  efficiently  service  clients.  While  the  local  clients  manage  their  own  states, 
one  centrally  located  repository  greatly  simplifies  configuration  management  and 
version  control.  Local  clients  can  open  prototypes  from  either  local  memory  or  from  the 
server  side.  They  can  also  save  to  either  location.  However,  the  project  manager 
controls  centrally  what  changes  get  into  the  master  copy  of  a  prototype.  Thus  when 
various  clients  submit  changes  to  a  prototype,  they  are  saved  into  the  user’s  centrally 
located  folder  and  the  project  manager  decides  when  and  how  to  access  them.  This 
arrangement  allows  the  project  manager  to  easily  maintain  control  over  the  merging 
process  and  the  resulting  configuration  and  versioning  decisions.  Users  can  only  read 
the  master  prototype,  and  only  when  the  project  manager  permits  it. 

B.  IMPLEMENTING  THE  CAPS  CLIENT-SERVER  ARCHITECTURE 

There  are  many  ways  in  which  a  distributed  CAPS  could  be  implemented.  The 
first  decision  is  what  language,  or  languages,  to  use.  The  original  CAPS  is  written 
largely  in  Ada,  C  and  C++.  Given  the  realities  of  writing  distributed  applications,  among 
other  considerations,  we  decided  that  Java  would  be  a  superior  language  with  which  to 
implement  a  distributed  CAPS.  Choosing  an  implementation  language  is  only  part  of 
the  total  implementation  decision.  The  other  part  is  determining  how  the 
communications  will  actually  take  place  in  a  distributed  system.  For  this,  we  decided 
that  the  Object  Management  Group’s  (OMG)  Common  Object  Request  Broker 
Architecture  (CORBA)  offered  the  best  possible  solution.  Our  reasons  for  these 
selections  are  detailed  below. 
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1 .  The  Selection  of  Java 


There  are  many  reasons  why  Java  is  the  language  of  choice  when  implementing  a 
distributed  application.  First,  the  ease  of  migrating  Java  across  different  machines  and 
operating  systems  is  an  enormous  advantage.  As  discussed  previously,  it  almost  a 
certainty  that  any  distributed  system  deployed  will  by  necessity  be  heterogeneous. 
Every  major  type  of  computer  and  operating  system  today  has  a  Java  Virtual  Machine 
(JVM)  written  for  it.  This  allows  Java  byte  code  written  on  one  type  of  machine  to 
execute  on  any  machine  that  has  a  JVM.  This  was  shown  to  work  while  implementing 
our  proof  of  concept  demonstration.  Byte  code  that  was  created  in  a  Windows  NT  PC 
environment  was  copied  to  a  Sun  Solaris  Unix  machine  and  successfully  executed 
without  any  alterations.  This  type  of  portability  will  greatly  simplify  implementing  a 
distributed  CAPS.  Secondly,  Java  was  created  as  language  to  operate  on  the  Internet 
and  World  Wide  Web  (WWW).  Thus  it  possesses  many  built-in  capabilities  that 
facilitate  network  operations.  Additionally,  Java  has  facilities  for  things  such  as  multi¬ 
threading,  garbage  collection  and  error  management  designed  into  the  language  that 
appreciably  reduce  the  difficulty  of  designing  an  application.  Lastly,  as  will  be 
discussed,  Java  is  a  natural  fit  with  CORBA  and  the  two  are  quickly  merging  in  the 
world  of  network  applications. 

2.  The  Selection  of  CORBA 

CORBA  provides  many  advantages  over  other  competing  middleware  solutions.  A 
review  of  CORBA  will  facilitate  a  discussion  of  these  advantages. 
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a. 


CORBA  Description 


As  previously  discussed,  it  is  assumed  that  a  distributed  CAPS  must 
perform  in  a  heterogeneous  environment.  While  heterogeneity  in  itself  is  not  negative 
and  may,  in  fact,  be  viewed  as  an  asset  to  be  leveraged,  it  does  present  challenges  to 
us  as  software  developers  desiring  to  implement  an  application  in  a  heterogeneous 
networked  system.  Heterogeneity  creates  the  need  for  middleware  that  can  enable  the 
sharing  of  objects,  functions  and  types  without  causing  extensive  software  re-work  for 
developers,  or  complex  work-arounds  for  users. 

The  Object  Management  Group  (OMG)  was  formed  in  1989  to  develop, 
adopt,  and  promote  standards  for  the  development  and  deployment  of  applications  in 
distributed  heterogeneous  environments.  Since  that  time,  the  OMG  has  grown  to  be  the 
largest  software  consortium  in  the  world,  and  has  developed  the  Object  Management 
Architecture  (OMA).  The  OMA  consists  of  an  Object  Model  and  a  Reference  Model. 
The  Object  Model  defines  how  objects  can  be  described,  and  the  Reference  Model, 
shown  in  Figure  4.1,  deals  with  interactions  between  those  objects.  In  the  Object 
Model,  clients  issue  requests  for  services  to  objects  (much  like  a  remote  procedure  call 
(RPC)).  The  implementations  of  these  objects  are  hidden  from  the  client.  A  key 
component  of  the  Reference  Model  is  the  Object  Request  Broker  (ORB),  which 
facilitates  communication  between  clients  and  objects.  CORBA  is  the  specification 
developed  by  the  OMG  that  details  the  interfaces  and  characteristics  of  the  ORB.  In 
CORBA  the  terms  “client”  and  “server”  are  not  rigidly  defined  roles.  The  CAPS  server 
could  handle  the  request  from  client  machines  and  in  turn  become  a  client  itself  when  it 
invokes  requests  on  some  ‘back  end’  implementation. 
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Figure  4.1  OMG  Reference  Model  Architecture  From  [SCHM99] 

In  CORBA,  an  application  consists  of  one  or  more  objects  that  may  reside 
on  the  same  or  different  platforms.  An  object  provides  service(s)  that  can  be 
“requested”  by  a  client.  Clients  obtain  services  from  an  object  by  making  “requests”  that 
consist  of  an  operation,  the  name  of  the  object  that  will  respond,  zero  or  more 
parameters,  and  an  optional  request  context.  The  object  may  or  may  not  return  results 
to  a  client,  and  will  return  an  exception  if  an  abnormal  condition  occurs.  Object 
implementations  may  be  written  in  a  variety  of  languages  and  may  exist  in  a  variety  of 
forms.  Essentially,  CORBA  allows  components  to  discover  each  other  and  interoperate 
on  an  object  bus.  However,  CORBA  does  much  more  than  just  create  a  simple  object 
bus,  as  shown  in  Figure  4.2.  It  also  provides  an  extensive  set  of  services  for  such 
things  as  creating  and  deleting  objects,  accessing  them  by  name,  putting  them  in 
persistent  storage,  externalizing  their  states  and  forming  ad  hoc  relationships  between 
objects.  Thus  you  can  design  an  ordinary  object  and  then  give  it  the  specific 
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characteristics  needed  for  a  distributed  application  by  using  CORBA’s  multiple 
inheritance.  [ORFA98] 


OEB-specdfic  interface 


(  )  STANDARD  PROTOCOL 


Figure  4.2  CORBA  ORB  Architecture  From  [SCHM99] 

Methods  can  be  invoked  statically  or  dynamically.  In  Static  Invocation,  a 
client’s  request  is  made  via  interface  definition  language  (IDL)  “stubs”  on  the  client  side, 
and  the  response  is  handled  by  IDL  “skeletons”  on  the  object  side.  The  stubs  and 
skeletons  interface  with  the  CORBA  ORB.  In  Static  Invocation,  the  IDL  Client  Stub 
converts  data  from  the  client’s  local  data  representation  (type)  to  the  Common  Data 
Representation  (CDR),  which  is  platform  and  language  independent.  On  the  object’s 
platform,  the  Object  Skeleton  executes  the  reverse  operation.  In  Dynamic  Invocation, 
requests  are  made  via  Dynamic  Invocation  Interface.  With  Dynamic  Invocation  the 
developer  is  afforded  more  flexibility.  In  Dynamic  Invocation,  the  Dynamic  Skeleton 


Interface  (DSI)  may  take  the  place  of  the  Static  Invocation  Object  Skeleton  to 
accomplish  data  conversion  at  run  time. 

CORBA  supports  two  types  of  (method)  invocation  semantics: 
synchronous  invocation  and  asynchronous  invocation.  Synchronous  invocation  is 
blocking.  The  client  will  invoke  the  method  and  block  until  it  receives  a  response  from 
the  server  (object  implementation).  Asynchronous  invocation  is  non-blocking.  The  client 
will  invoke  a  method,  continue  its  computation,  and  collect  results  as  they  arrive.  With 
non-blocking  primitives,  the  SEND  primitive  returns  control  to  the  requesting  program  as 
soon  as  the  message  is  copied  from  the  user  buffer  to  the  kernel  buffer.  The 
corresponding  object  that  executes  the  RECEIVE  primitive  signals  its  intention  to 
receive  a  message,  provides  a  buffer  into  which  the  message  will  be  copied  and 
continues  to  execute.  [POPE98] 

Through  the  IDL  stubs,  a  client  can  use  RPC-style  semantics 
(synchronous),  or  by  using  Dynamic  Invocation  Interface  (Dll)  a  client  can  use 
SEND/RECEIVE  semantics.  Using  Dll  allows  a  client  to  directly  access  the  underlying 
request  mechanisms  provided  by  the  ORB.  Applications  use  Dll  to  dynamically  issue 
requests  to  objects  without  requiring  IDL  stubs  to  be  linked  in.  The  Dll  allows  clients  to 
make  non-blocking  “deferred  synchronous”  (separate  SEND  and  RECEIVE  operations) 
and  one  way  (SEND  only)  calls.  [POPE98] 

Many  industry  leaders,  including  IBM,  Novell,  BorlandA/isigenic,  SunSoft, 
Netscape,  Oracle  and  JavaSoft  just  to  name  a  few,  have  recognized  the  importance  of 
CORBA  middleware  in  realizing  the  potential  of  heterogeneous,  distributed 
systems[ORFA98j.  In  fact,  CORBA  is  now  part  of  the  Defense  Information 
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Infrastructure  Common  Operating  Environment  (Dll  COE)  standard  web  browser,  and  is 
finding  increasing  use  in  Department  of  Defense  applications.  The  utility  of  CORBA 
lies  in  its  ability  to  integrate  diverse  applications  across  a  variety  of  networks  and 
network  protocols.  CORBA’s  language  independent  IDL’s  allow  objects  to  be  used  from 
a  variety  of  programming  languages,  including  COBOL,  C,  C++,  Ada,  Smalltalk,  Perl 
and  Java.  CORBA-based  applications  are  independent  of  network  protocols  so  they 
may  be  run  in  a  distributed  system  over  a  diverse  network.  These  attributes  ensure 
CORBA’s  tremendous  usefulness  in  a  heterogeneous  environment. 

b.  CORBA  Advantages  for  a  Distributed  CAPS 

CORBA  certainly  is  not  the  only  solution  for  implementing  an  application  in 
a  distributed  environment.  The  other  prominent  options  include  legacy  solutions  that 
predate  the  ORB  concept  such  as  Java  sockets,  Common  Gateway  Interface  (CGI) 
scripts  with  Hypertext  Transfer  Protocol  (HTTP)  and  Java  Servlets.  Non-CORBA  ORBs 
are  JavaSoft’s  Remote  Method  Invocations  (RMI)  and  Microsoft’s  Distributed 
Component  Object  Model  (DCOM).  As  for  simple  performance  metrics,  the  fastest 
implementation  for  operating  over  a  network  is  a  socket  using  a  buffered  data  stream. 
However,  as  we’ll  discuss  below,  this  is  not  a  realistic  choice  for  implementing  a 
distributed  CAPS.  The  three  ORBs,  CORBA,  DCOM  and  RMI,  are  very  close  in 
performance  and  as  a  group  are  a  little  less  than  twice  as  slow  as  a  socket.  Servlets 
are  well  over  an  order  of  magnitude  slower  than  a  socket  and  the  CGI/HTTP 
combination  is  well  over  two  orders  of  magnitude  slower.  [ORFA98] 

The  three  legacy  solutions  all  suffer  from  the  fact  that  they  operate  at  very 
low  levels  of  abstractions.  Sockets  in  particular  are  a  relatively  primitive  model. 
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Sockets  are  ‘close  to  the  wire’  in  the  sense  that  they  are  the  lowest  level  of  abstraction 
available.  This  accounts  for  their  efficient  performance  but  it  also  makes  them  difficult 
to  program.  The  other  solutions  build  upon  sockets  as  a  transport  mechanism  while 
shielding  users  from  having  to  deal  with  the  details  of  socket  programming.  CGI  scripts 
over  HTTP  is  the  current  predominant  model  for  three  tiered  applications  over  the 
internet.  HTTP  provides  simpler  semantics  on  top  of  sockets  which  CGI  scripts  use  to 
communicate  between  clients,  servers  and  ‘back  end’  resources.  However,  besides 
being  incredibly  slow,  other  disadvantages  include  a  lack  of  typed  parameter  support 
and  object  reference  persistence,  a  relatively  low  level  of  abstraction  and  poor 
scalability.  A  Servlet  is  a  small  piece  of  Java  code  loaded  onto  a  server.  It  operates 
much  as  CGI  but  it  overcomes  some  of  the  worst  performance  degradations  by 
remaining  in  memory  between  request  and  by  staying  connected  to  ‘back  end’ 
resources.  As  with  CGI  though,  the  lack  of  typed  interfaces  result  in  a  proliferation  of 
interfaces  as  the  number  of  methods  grows  and  each  method  must  be  prepared  to 
marshal  and  unmarshal  multiple  data  types. 

RMI  and  DCOM  share  many  of  the  advantages  of  CORBA  for  developing 
distributed  applications.  There  are  however,  some  significant  drawbacks  to  both.  RMI 
and  DCOM  both  lack  the  comprehensive  services  and  facilities  that  are  available  for 
CORBA.  These  include  a  Naming  Service,  Event  Service,  Property  Service, 
Relationship  Service,  Lifecycle  Service,  Security  Service  and  a  continually  growing  host 
of  CORBA  facilities  such  as  mobile  agents,  data  interchange,  workflow,  firewalls  and 
business  object  frameworks.  The  ultimate  goal  of  CORBA  facilities  is  to  provide  an  IDL 
interface  for  virtually  every  networked  service.  RMI  is  an  all  Java  implementation,  which 
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could  potentially  become  a  problem  at  some  point  in  the  future.  It  is  also  proprietary 
and  thus  doesn’t  interact  with  other  ORBs.  The  extremely  proprietary  nature  of  DCOM 
is  certainly  it’s  biggest  disadvantage.  Microsoft  only  produces  Window  versions  of 
DCOM  and  in  addition,  it  must  run  in  their  JVM.  There  are  some  third  party  attempts  at 
porting  it  to  other  platforms,  but  so  far  these  have  met  with  limited  success.  Even  if 
successfully  ported,  there  exist  deficiencies  in  the  design  of  DCOM  which  make  it 
inferior  to  CORBA.  It  does  not  follow  the  object  oriented  model  since  it  precludes 
inheritance.  There  are  work-arounds  but  they  can  be  cumbersome.  Also,  object 
references  are  not  persistent  and  due  to  the  limitations  of  working  only  on  Window 
platforms,  it  is  not  scalable. 

In  light  of  the  discussion,  it  becomes  clear  that  CORBA  addresses  many 
of  the  issues  we  initially  identified  as  pertinent  to  developing  a  distributed  CAPS.  With 
CORBA,  the  type  of  network  becomes  irrelevant  to  the  operation  of  a  distributed  CAPS. 
Indeed,  the  proof  of  concept  implementation  done  for  this  work  started  on  a  single  PC 
and  then  migrated  seamlessly  to  first  an  all  PC  environment  and  then  to  one  where  the 
client  resided  on  a  PC  and  the  server  on  a  Sun  Solaris  Unix.  The  next  step,  to  operate 
over  the  internet,  would  be  just  as  smooth  a  transition.  Clearly,  the  heterogeneous 
nature  of  any  large  network  becomes  immaterial  given  the  fact  that  every  important 
language  has  an  IDL  mapping  and  every  major  type  of  operating  system  supports 
CORBA.  The  fact  that  no  special  hardware  is  required  is  also  a  plus.  CORBA’s 
extensive  support  for  exceptions  and  the  ability  to  implement  user  defined  exceptions 
provide  for  greatly  improve  fault  tolerance.  Despite  the  intuitive  feeling  that  the 
overhead  of  CORBA  must  be  significant,  it  is  actually  shown  to  be  quite  acceptable. 
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With  the  introduction  of  real-time  CORBA  this  year,  latency  should  become  even  less  of 
an  issue.  Lastly,  the  CORBA  services  and  facilities  provide  extensive  support  for 
current  and  future  growth. 
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V.  A  DISTRIBUTED  CAPS  PROOF  OF  CONCEPT  IMPLEMENTATION 

The  primary  objective  in  the  initial  implementation  was  to  demonstrate  the 
efficacy  of  a  distributed  CAPS  design  using  Java  and  CORBA.  The  first  step  in  this 
process  was  completed  with  the  HSI  which  was  written  in  Java  and  included  a  PSDL 
editor.  There  was,  however,  little  other  functionality  built  into  the  initial  HSI.  Our  goal 
was  to  create  an  implementation  where  the  HSI  would  run  on  a  PC  and  remotely  invoke 
methods  on  a  CAPS  server  located  on  a  Sun  Solaris  Unix  machine.  The  mechanism  for 
these  invocations  would  be  CORBA.  Since  this  was  a  proof  of  concept  implementation, 
only  selected  functionality  was  demonstrated  in  order  to  prove  the  effectiveness  of  the 
Java/CORBA  combination  before  attempting  large  scale  development. 

A.  PRODUCT  CHOICES  FOR  IMPLEMENTATION 

There  are  many  possible  environments  for  developing  Java  code  and  currently 
there  are  three  major  suppliers  of  CORBA/Java  ORBs.  In  selecting  an  environment  for 
developing  Java  code,  the  continuum  runs  from  using  the  Java  Developer  Kit  (JDK) 
supplied  by  JavaSoft  and  a  text  editor  which  are  a  very  minimalist  approach  to  full 
feature,  comprehensive  integrated  development  environments  (IDE).  Java  IDEs  are 
offered  by  a  host  of  vendors.  We  decided  to  use  the  newest  version  of  the  JavaSoft 
JDK,  1 .2.2.  There  were  several  reasons  for  this.  First,  the  JDK  is  supplied  free  of 
charge.  Secondly,  in  keeping  with  the  walk  before  running  philosophy,  choosing  the 
JDK  gave  us  a  simpler,  more  straightforward  design  environment.  It  allowed  us  to 
concentrate  on  creating  a  distributed  CAPS  without  the  distraction  of  all  the  bells  and 
whistles  that  accompany  the  more  feature  laden  IDEs.  The  documentation  with  the  JDK 
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is  also  very  comprehensive.  As  will  be  discussed  below,  the  JDK  has  one  additional 
advantage  -  a  built-in  Java  ORB  that  is  fully  CORBA  compliant. 

The  three  Java  ORBs  available  today  are  JavaSoft’s  JAVA  IDL,  Iona’s  OrbixWeb 
3.0  and  BorlandA/isigenic’s  VisiBroker  for  Java  3.1.  Much  of  the  same  reasoning  for 
selecting  JavaSoft’s  JDK  for  writing  the  Java  code  went  into  the  selection  of  using 
JavaSoft’s  Java  IDL  for  the  ORB  in  our  implementation.  While  far  from  a  full  feature 
ORB  (it  lacks  such  things  as  a  non-volatile  Naming  Service  and  many  of  the  add-on 
services)  it  is  fully  CORBA  compliant.  In  our  case,  the  simpler  ORB  was  more  a  benefit 
than  a  disadvantage.  As  a  distributed  CAPS  moves  from  the  research  stage  to  a 
production  release,  the  work  done  can  be  easily  migrated  to  a  more  full  feature  ORB. 
Also,  it  is  very  likely  that  JavaSoft  will  continue  to  improve  the  Java  IDL  and  such  a 
migration  may  not  even  be  necessary.  Java  IDL  is  already  built  into  the  JDK 
environment.  We  did  discover  that  some  bugs  exist  in  versions  of  JDK  before  1.2.2 
which  prevented  the  Java  IDL  from  operating  properly.  The  IDL  to  Java  compiler 
worked  correctly  but  using  a  version  earlier  than  1.2.2  resulted  in  exceptions  when 
attempting  to  connect  to  the  ORB. 

B.  IMPLENTATION  DECISIONS 

The  HSI,  as  implemented  by  [DURA99],  provided  the  GUI  by  which  a  user  could 
create  a  prototype  with  the  graphical  editor  and  generate  the  corresponding  PSDL  code. 
It  could  open  from  and  save  to  a  local  memory  location  or  the  user’s  allocated  memory 
storage  location  on  a  network.  The  entire  process  was  one  controlled  by  the  current 
instantiation  of  the  HSI  created  by  the  user.  In  order  to  demonstrate  the  viability  of  a 
distributed  CAPS  operating  in  a  client-server  paradigm,  we  had  to  separate  out  some  of 
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the  functionality  into  distinct  client  and  server  processes.  Additionally,  we  wanted  to 
incorporate  some  of  the  tasks  from  the  original  stand-alone  CAPS  into  our  client-server 
designed  one.  The  IDL  file  and  the  two  files  that  implement  the  server  are  listed  in 
Appendix  B.  The  files  generated  by  the  IDL-to-Java  compiler  are  listed  in  Appendix  C. 
The  HSI  files  that  were  modified  to  implement  the  remote  calls  to  the  server  are  listed  in 
Appendix  D.  All  three  appendixes  include  both  source  files  and  the  corresponding 
Javadoc  generated  documentation. 

First,  we  decided  that  the  user  should  be  able  to  open  an  existing  prototype  from 
either  the  local  memory  or  from  prototypes  stored  on  the  server  side  of  the  network. 
The  user  was  also  given  the  ability  to  save  files  on  the  server  side  as  well  as  in  his/her 
own  memory  space  as  before.  This  remote  save  was  implemented  as  the  commit 
function  of  the  HSI.  We  decided  to  incorporate  execution  of  the  translate  function  on 
the  server  side  in  order  to  further  extend  the  work  began  in  [DURA99],  When  a  user 
selects  the  translate  function  during  a  HSI  session,  the  current  prototype  file  is 
transferred  to  the  server  where  the  translate  is  actually  invoked.  The  Ada  files 
generated  are  stored  on  the  server  in  the  user’s  directory  and  a  message  notifying  the 
user  of  a  successful  translate  is  sent  to  the  HSI.  Likewise,  the  user  is  notified  after  a 
prototype’s  PSDL  file  is  successfully  saved  to  the  server  side  when  the  user  invokes  the 
commit  function  from  the  HSI.  On  the  server  side,  when  the  translate  function  is 
invoked,  a  shell  script  is  called  which  performs  the  actual  translating.  This  is  not  a  true 
three  tier  design  but  as  the  primary  objective  was  to  test  the  communication  between 
the  HSI  and  a  remotely  located  server,  it  was  acceptable.  As  this  research  matures,  it 
may  be  that  ultimately  the  server  communicates  with  the  ‘back  end’  implementation 
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doing  the  actual  work  over  a  second  CORBA  object  bus.  In  essence,  the  server  would 
become  the  client  in  a  client-server  relationship  with  the  ‘back  end’  implementation. 

The  interfaces  of  the  methods  needed  to  implement  this  initial  design  were 
described  in  CORBA  IDL  and  compiled  using  the  IDL-to-Java  compiler  in  JDK  1.2.2. 
When  invoking  the  IDL-to-Java  compiler,  the  command  line  argument  -fno-cpp  is  used 
in  order  to  disable  the  C++  preprocessor  that  is  defaulted  enabled.  This  preprocessing 
is  not  needed  and  prevented  the  IDL-to-Java  from  performing  properly  in  the  lab.  The 
result  were  15  .Java  files  which  represented  all  the  classes  required  to  implement  the 
interfaces  described  in  the  initial  IDL  description.  The  corresponding  .class  files  were 
created  by  the  JDK  1.2.2  Java  compiler.  The  files  were  responsible  for  the  actual 
operation  of  the  CORBA  object  bus  by  marshalling  and  unmarshalling  data  being 
passed  over  the  network  between  the  client  HSI  and  the  server  side.  Additionally,  they 
provide  stub  and  skeleton  implementations  containing  all  the  necessary  information  for 
proper  communications  with  the  ORB.  They  simply  had  to  be  extended  and  the 
desired  functionality  added,  e.g.  saving  or  translating  a  file,  and  they  were  ready  to  be 
compiled  into  .class  files  by  the  Java  compiler. 

Since  this  was  a  proof  of  concept  demonstration,  robustness,  ease  of  use  and 
efficiency  were  not  primary  considerations.  Minimal  error  checking,  such  as  ensuring 
that  a  prototype  was  opened  in  the  HSI  before  invoking  the  translate  function  on  the 
server,  was  incorporated.  However,  other  than  the  built  in  mechanisms  such  as  type 
checking,  not  much  work  was  done  in  this  area.  Given  the  effectiveness  of  Java 
exceptions  and  the  ease  of  creating  user  defined  exceptions  in  CORBA,  this  will  not  be 
an  impediment  to  future  work.  Likewise,  three  pieces  of  information  are  currently 
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entered  on  the  command  line  when  starting  the  HSI  or  the  server.  On  starting  the  HSI, 
PROTOTYPEHOME  and  CAPSUser  tell  the  system  where  the  prototype  PSDL  files  are 
located  and  who  the  current  user  is.  In  the  event  that  PROTOTYPEHOME  is  not 
entered,  the  system  will  look  in  the  user’s  home  directory  as  a  default.  Again,  the  default 
is  to  the  home  directory  of  who  ever  starts  the  CAPS  server.  These  could  easily  be 
incorporated  into  the  respective  GUIs  in  future  work. 

The  sequence  of  events  that  brings  the  entire  system  on  line  are  quite 
straightforward.  First,  on  the  machine  that  is  hosting  the  server,  start  the  naming 
service.  Second,  in  another  process,  e.g.,  a  separate  DOS  window,  start  the  server 
implementation.  Third,  start  the  HSI  on  another  machine  (it  can  be  started  on  the  same 
machine  in  a  third  process).  For  all  three,  you  must  include  the  desired  communication 
port.  It  must  be  the  same  for  three  processes.  Additionally,  for  the  client  HSI  you  must 
include  the  internet  location  of  the  host  running  the  server.  More  advanced 
implementations  can  eliminate  these  requirements.  The  following  are  examples  of  the 
actual  semantics  needed.  To  invoke  the  naming  service,  use  “tnameserv 
-ORBInitialPort  1050.”  For  the  server,  use  “java 

DCAPSJavaHome=$CAPSHOME\.caps  CapsServer  -ORBInitialPort  1050”.  Lastly,  for 
the  HSI  use  “java  -PROTOTYPEHOME=\jdk2\.caps  -  DCAPSUser=kreeger  caps.Caps  - 
ORBInitialHost  131.120.8.58  -ORBInitialPort  1050”. 
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VI.  CONCLUSIONS  AND  FUTURE  WORK 

Our  initial  tests  are  very  encouraging.  We  were  able  to  easily  integrate  the 
existing  Java  HSI  running  on  a  Windows  NT  machine  into  a  client-server  arrangement 
with  the  server  running  on  a  Sun  Solaris  Unix  machine.  We  successfully  created 
prototypes  in  the  graphical  editor  of  the  HSI  and  saved  the  resulting  PSDL  files  both  to 
the  HSI’s  memory  and  transferred  it  over  the  network,  where  the  server  stored  in  its 
memory.  We  successfully  opened  PSDL  files  from  both  locations  and  displayed  them  in 
the  graphical  editor.  Additionally,  we  sent  PSDL  files  over  the  network  to  the  server 
where  they  were  translated  and  the  corresponding  Ada  files  generated.  Thus,  there 
appears  to  be  little  doubt  about  the  ability  of  the  current  CAPS  to  be  implemented  in  a 
client-server  design  that  functions  over  any  size  network,  including  ultimately  the 
Internet.  The  machinery  that  makes  this  not  only  possible,  but  even  a  reasonable  effort, 
is  CORBA.  CORBA  makes  it  feasible  to  convert  the  current  CAPS  to  a  client-server 
architecture  while  preserving  much  of  the  existing  codebase.  It  is  straightforward  to 
instantiate  a  CAPS  object  on  the  server  and  then  send  a  reference  object  to  the  CAPS 
object  to  any  client.  The  users  on  the  client  side  interact  with  the  HSI’s  extremely 
intuitive  interface  and  whenever  they  need  CAPS  functionality,  such  as  translate,  the 
HSI  simply  invokes  the  method  on  the  CAPS  object  reference  that  was  received  from 
the  server.  Thus  much  of  the  more  complicated  code  that  has  been  developed  for  the 
stand-alone  CAPS  can  continue  to  be  used.  To  this  code,  the  origins  of  the  request  are 
irrelevant.  As  long  as  the  proper  parameters  are  passed  in,  the  expected  result  will  be 
produced  and  where  the  result  is  ultimately  sent  doesn’t  matter.  This  arrangement 
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allows  the  HSI  to  manage  the  user  inputs  to  a  prototype  design  locally.  This  is  a  very 
efficient  manner  for  this  type  of  operations.  The  more  heavy  duty,  less  frequently 
invoked  functionality  can  reside  on  the  server  side  of  the  network.  The  additional 
benefit  of  this  design  is  that  as  more  effective  means  of  executing  these  services  are 
implemented  or  additional  requirements  are  discovered,  it  is  a  much  simpler  matter  to 
update  the  single  copy  of  the  code  located  on  the  server  side  compared  to  trying  to 
update  code  on  a  variety  of  different  client  machines  across  an  entire  network.  As  long 
as  the  interfaces  remain  unchanged,  any  alterations  in  one  tier  of  the  architecture  will 
remain  transparent  to  the  other  tiers. 

As  for  the  future,  much  remains  to  be  done  in  order  to  fully  realize  the  potential  of 
a  distributed  CAPS.  The  work  done  thus  far  has  clearly  shown  the  potential  that  exists. 
However,  to  become  a  practical  system  for  creating  and  managing  prototyping  for  large 
software  projects,  a  distributed  CAPS  must  be  fully  functional  and  much  more  robust 
than  at  present.  The  next  logical  phase  of  this  research  should  focus  on  two  parallel 
tracks. 

On  the  HSI  the  effort  should  concentrate  on  implementing  the  rest  of  the  existing 
functionality  for  the  current  CAPS  and  on  engineering  production  quality  robustness  into 
the  HSI.  The  implementations  of  the  commit  and  translate  functions  in  this  work  provide 
an  example  of  how  to  invoke  from  the  HSI  existing  CAPS  methods  on  a  CAPS  server 
and  return  the  results  to  the  HSI.  Incorporating  additional  methods  into  the  IDL 
interface  definition  and  recompiling  it  are  straightforward  processes.  This  will  produce 
the  files  necessary  to  implement  the  additional  methods  on  the  server  side  and  the  HSI. 
The  second  part  of  the  effort  for  improving  the  HSI  is  easily  done  concurrently  with  the 
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first  part.  As  additional  methods  are  included  into  the  HSI,  every  effort  should  be  made 
to  ensure  production  quality  robustness.  The  ease  of  creating  user  defined  exceptions 
in  both  Java  and  CORBA  simplify  this  effort  tremendously. 

In  parallel  with  the  HSI  work,  there  remain  tasks  to  be  completed  on  the  CAPS 
software.  First,  while  comprehensive  theoretical  work  has  been  done  on  every  aspect 
of  CAPS,  there  remains  functionality  that  either  needs  to  be  completed  or  enhanced. 
This  is  especially  true  in  regards  to  the  reusable  database.  Finishing  this  work  in 
conjunction  with  the  HSI  work  provides  the  opportunity  to  tightly  coordinate  efforts. 
Secondly,  the  CAPS  method  implementations  should  be  separated  out  from  the  CAPS 
server.  This  would  allow  the  CAPS  server  to  be  as  efficient  as  possible  and  easily  scale 
to  a  larger  number  of  users.  Furthermore,  by  isolating  the  actual  method  of 
implementations  from  the  CAPS  server,  they  can  be  modified  and  updated  more  easily. 

In  conclusion,  the  endeavor  to  deploy  a  distributed  CAPS  is  both  feasible  and 
necessary.  The  emergence  of  the  Java/CORBA  technology  supplies  the  means  by 
which  migrating  CAPS  from  an  isolated  system  to  a  fully  functional  distributed  system 
becomes  not  just  possible,  but  quite  manageable.  That  is  fortunate  timing,  for  if  CAPS 
is  to  continue  to  be  a  driving  force  in  software  engineering  research  it  must  adapt  to  the 
new  realities  of  a  networked  world. 
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APPENDIX  A:  EXPANDED  USE  CASES 


Selected  used  cases  are  detailed  below  in  expanded  format: 


Use  Case: 

Actors: 

Type: 

Purpose: 

Overview: 


Cross  Reference: 


U3.  Open  project 

User 

primary  and  essential 
Allow  user  to  open  a  project 

After  logging  into  CAPS,  user  can  select  an  existing  project  and 
open  it,  if  he  has  the  proper  authorization  from  the  project  manager. 
If  the  user  has  project  manager  privileges,  they  can  open  a  new 
project. 

Functions:  R2.3,  R4.2,  R4.3 

Use  Cases:  User  must  have  completed  the  Start-up  and  Log  in  use 
cases 


Section:  Main 

Typical  Course  of  Action 

Actor  Action  System  Response 

1 .  This  use  case  begins  after  the  user 
has  successfully  started  and  logged 
into  CAPS 

2.  The  user  chooses  to  open  a  new  or 
existing  prototype 
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a.  If  the  user  chooses  a  new 
prototype,  see  section  Open  New 
Prototype 

b.  If  the  user  chooses  an  existing 
prototype,  see  section  Open  Existing 
Prototype 

Section:  Open  New  Prototype 

Typical  Course  of  Action 
Actor  Action 

1.  The  user  selects  the  new  prototype 
option 

4.  The  user  inputs  new  prototype 
information 

Section:  Open  Existing  Prototype 

Typical  Course  of  Action 
Actor  Action 

1.  The  user  selects  the  open  existing 
prototype  option 

3.  The  user  highlights  the  desired 
prototype  and  selects  to  open  it 


System  Response 

2.  The  system  verifies  the  user  has 
project  manager  level  privileges. 

3.  The  system  prompts  the  user  for 
new  prototype  information 

5.  A  new  prototype  is  created 


System  Response 

2.  System  presents  the  user  with  a  list 
of  existing  prototypes  within  a  file 
structure  that  can  be  navigated 
4.  The  selected  prototype  is  loaded  at 
the  users  workstation 
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U4.  Modify  prototype 

User 

primary  and  essential 
Allow  user  to  modify  a  prototype 

After  opening  a  prototype,  the  user  will  be  able  to  make  changes  to 
the  graphical  interface  of  the  control  flow  diagram  or  to  the  text 
boxes  associated  with  either  objects  or  data  streams  in  the 
diagram.  These  changes  will  be  automatically  reflected  in  the 
PSDL  code.  The  user  can  record  user  comments,  stakeholder 
comments  and  requirements  for  the  system  being  prototyped. 
Additionally,  the  user  can  directly  access  the  PSDL  code  and 
change  it  manually. 

Cross  Reference:  Functions:  R1.1,  R1.2,  R1.3,  R1.4,  R1.5,  R1.6,  R1.7,  R1.21,  R4.4, 
R4.5 

Use  Cases:  User  must  have  completed  the  Start-up,  Log  in  and 
Open  Project  use  cases 

Section:  Main 

Typical  Course  of  Action 

Actor  Action  System  Response 

1.  This  use  case  starts  after  the  user 
has  opened  a  prototype 


Use  Case: 

Actors: 

Type: 

Purpose: 

Overview: 
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2.  The  user  can  make  changes 
graphically  or  textually  to  the  control 
flow  diagram  or  may  edit  the  actual 
PSDL  code 

a.  If  user  makes  graphical  changes, 
see  section  Graphical  Changes 

b.  If  user  makes  textual  changes,  see 
section  Textual  Changes 

c.  If  the  user  edits  the  PSDL  code, 
see  section  Edit  PSDL  Code 

Section:  Graphical  Changes 
Typical  Course  of  Action 

Actor  Action  System  Response 

1 .  User  selects  graphical  input  from  the  2.  The  changes  made  by  the  user  are 
menu  of  inputs,  such  as  circle  or  line,  displayed  in  the  diagram  and  the  PSDL 
or  selects  an  existing  graphical  code  in  main  memory  is  generated 
representation  within  the  control  flow  and/or  modified 
diagram  and  manipulates  it  within  the 
diagram 
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Section:  Textual  Changes 

Typical  Course  of  Action 
Actor  Action 

1.  The  user  chooses  an  existing 
graphical  object  from  the  control  flow 
diagram  and  selects  to  add  textual 
input  to  it 

3.  The  user  makes  the  desired 
changes  to  the  textual  input  box  and 
confirms  done  when  the  input  is 
completed 

Section:  Edit  PSDL  Code 

Typical  Course  of  Action 
Actor  Action 

1  .The  user  selects  the  option  to  directly 
edit  the  PSDL  code  from  a  CAPS  menu 
3.  The  user  makes  changes  to  the 
PSDL  code  and  selects  save  or  closes 
the  editor  when  done 


System  Response 

2.  The  text  box  for  the  graphical  object 
selected  is  displayed 

4.  The  text  box  is  no  longer  displayed, 
the  changes  are  accepted,  the  PSDL 
code  is  generated  and/or  modified  in 
main  memory  and  if  applicable  the 
diagram  presentation  is  modified 


System  Response 

2.  The  PSDL  code  for  the  prototype  is 
displayed  within  a  text  editor 

4.  The  PSDL  code  is  modified  in  main 
memory 

5.  The  modified  PSDL  code  is 
validated  for  correctness  before  the 
user  can  exit  the  text  editor 
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Use  Case: 

Actors: 

Type: 

Purpose: 

Overview: 


Cross  Reference: 


U5.  Retrieve  component  from  reuse  database 

User 

primary  and  essential 

To  retrieve  reusable  components  from  library 
The  user  accesses  the  reuse  database  and  inputs  search 
parameters.  CAPS  responds  with  no  match,  unique  match  or  a  list 
of  possible  matches.  CAPS  generates  an  alert  if  there  is  an  error  in 
transmission  and  an  acknowledgement  if  the  transfer  is  successful. 
Functions:  R1.21,  R3.2,  R3.4,  R3.6 

Use  Cases:  User  must  have  completed  the  Start-up,  Log  in  and 
Open  Project  use  cases 


Section:  Main 

Typical  Course  of  Action 
Actor  Action 

1 .  The  user  selects  option  from  CAPS 
menu  to  retrieve  component  from 
reusable  component  library 


3.  The  user  inputs 

the 

desired 

component  parameters 

and 

selects 

retrieve 

System  Response 

2.  An  input  box  is  displayed  for  the  user 
to  input  the  desired  parameters  of  the 
component  to  be  returned 

4.  The  parameters  are  sent  to  the 
reuse  component  library,  possible  over 
a  network  to  a  remote  site 

5.  The  parameters  are  accepted,  a 
query  formulated  and  the  reuse 
component  library  searched 
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7.  The  user  selects  the  desired  6.  The  user  is  informed  that  there  was 
component,  if  one  available  a  match,  multiple  possible  matches  or 

no  match 

8.  A  copy  of  the  selected  component  is 
returned  to  the  user 

9.  The  user  is  notified  that  the  transfer 
was  successful 


Alternate  Courses 

•  Line  9.  If  the  transfer  is  unsuccessful,  the  user  is  notified.  The  type  of  error  is 
displayed,  if  known 


Use  Case: 
Actors: 

Type: 

Purpose: 

Overview: 

Cross  Reference: 


U7.  Modify  GUI  for  displaying  prototype  execution 

User 

primary  and  essential 

To  modify  the  GUI  generated  to  display  prototype  functionality 

User  selects  and  then  edits  the  files  that  provide  functionality  for 

displaying  prototype  execution 

Functions:  R1.4,  R1.5,  R1.6,  R1.7,  R1.8,  R1.9 

Use  Cases:  User  must  have  completed  the  Start-up,  Log  in  and 

Open  Project  use  cases  and  have  completed  the  Generate 

Executable  Prototype  use  case  sometime  previously  (not 

necessarily  the  same  session) 
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Section:  Main 


Typical  Course  of  Action 

Actor  Action  System  Response 

1.  This  use  case  starts  after  the  user 
has  opened  a  prototype 

2.  The  user  can  make  changes  to  the 
source  code  to  affect  prototype 
functionality  or  to  the  prototype 
graphical  interface 

a.  If  user  makes  functionality 
changes,  see  section  Functional 
Changes 

b.  If  user  makes  graphical  interface 
changes,  see  section  Interface 
Changes 

Section:  Functional  Changes 

Typical  Course  of  Action 
Actor  Action 

1.  The  user  selects  the  edit  source  file 
option  from  a  CAPS  menu 


System  Response 

2.  A  list  of  normal  programming  source 
files  (e.g.  Ada  or  Java)  within  the 
current  prototype  is  displayed 
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3.  The  user  selects  the  source  file  to 
edit 

5.  The  user  makes  changes  to  the  file 

6.  The  user  saves  the  file 

8.  The  user  quits  the  file 

9.  The  user  quits  the  editor 


Section:  Interface  Changes 
Typical  Course  of  Action 
Actor  Action 

1.  The  user  selects  the  edit  interface 
option  from  a  CAPS  menu 

3.  The  user  makes  the  desired 
changes  to  the  prototype  GUI 

4.  The  user  selects  the  generate  code 
option  from  the  GUI  builder 

6.  The  user  saves  the  file(s) 

8.  The  user  quits  the  GUI  builder 


4.  The  selected  file  is  opened  in  a  text 
editor 

7.  The  file  is  written  to  persistent 
storage 

10.  The  user  is  queried  about  saving 
any  unsaved  changes,  which  will  be 
saved  to  persistent  storage  and  the 
editor  is  closed 

System  Response 

2.  A  GUI  builder  is  invoked  with  the 
current  prototype  GUI  opened 

5.  Source  code  for  the  prototype  GUI, 
which  is  controlled  by  the  CAPS 
generated  control  source  code,  is 
automatically  generated 

7.  The  file(s)  is  written  to  persistent 
storage 
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Use  Case: 

Actors: 

Type: 

Purpose: 

Overview: 


Cross  Reference: 


U8.  Generate  Executable  Prototype 

User 

primary  and  essential 
Prepare  a  prototype  for  execution 

The  user  translates  the  prototype  in  order  to  create  source  code  in 
an  implementation  language  from  the  PSDL  and  link  it.  The  user 
will  then  verify  through  CAPS  that  all  static  hard  real  time 
constraints  are  met.  The  user  will  then  compile  the  prototype 
source  code. 

Functions:  R1.9,  R1.10,  R1.11 

Use  Cases:  User  must  have  completed  the  Start-up,  Log  in  and 
Open  Project  use  cases 


Section:  Main 

Typical  Course  of  Action 
Actor  Action 

1 .  The  user  selects  the  translate  option 
from  a  CAPS  menu 

3.  The  user  selects  the  schedule  option 
from  a  CAPS  menu 

5.  The  user  selects  the  compile  option 
from  a  CAPS  menu 


System  Response 

2.  PSDL  code  for  prototype  is  used  to 
generate  3rd  generation  object  oriented 
language  source  code 
4.  All  static  hard  real  time  constraints 
are  verified  as  met 

6.  All  source  files  are  compiled  and 
executable  files  created 
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Alternate  Courses 


•  Line  4.  Some  static  hard  real  time  constraint  is  missed.  CAPS  generates  an  alert  for 
the  user. 


Use  Case: 

Actors: 

Type: 

Purpose: 

Overview: 


Cross  Reference: 


U9.  Execute  the  prototype 

User 

primary  and  essential 

Execute  the  prototype  and  perform  analysis  of  system  constraints 
The  user  will  execute  the  prototype.  As  the  user  test  the  prototype 
functionality,  CAPS  will  verify  that  all  dynamic  hard  real  time, 
concurrency  and  network  constraints  are  met.  CAPS  will  allow  the 
user  to  record  stakeholder  and/or  user  comments. 

Functions:  R1.1,  R1.2,  R1.3,  R1.12,  R1.13,  R1.14,  R1.15,  R1.16 
Use  Cases:  User  must  have  completed  the  Start-up,  Log  in  and 
Open  Project  use  cases  and  have  completed  the  Generate 
Executable  Prototype  use  case  sometime  previously  (if  not 
immediately  after  generating  the  executable  prototype,  you  may 
execute  a  prototype  that  doesn't  have  the  most  recent  changes) 
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Section:  Main 


Typical  Course  of  Action 
Actor  Action 

1 .  The  user  selects  the  execute  option 
from  a  CAPS  menu 

3.  The  user  test  the  functionality  of  the 
designed  system  with  manual  inputs  or 
scripted  tests 


7.  The  user  selects  the  record 
comments  option  from  a  CAPS  menu 

9.  The  comments  are  entered  and  the 
comment  entry  box  deselected 


System  Response 

2.  The  prototype  GUI  interface  is 
generated  and  execution  of  the  system 
being  designed  begins 

4.  Dynamic  hard  real  time  constraints 
are  verified  met 

5.  If  the  designed  system  is  multi¬ 
threaded,  concurrency  constraints  are 
verified  met 

6.  If  the  designed  system  is  distributed, 
network  constraints  are  verified  met 

8.  A  menu  is  displayed  that  allows  the 
choice  of  selecting  user  or  stakeholder 
comment  inputs 

10.  The  comments  are  saved  to 
persistent  storage  and  become  part  of 
the  project  record 


Alternate  Courses 

•  Line  4.  Dynamic  hard  real  time  constraints  are  not  met.  CAPS  generates  an  alert  for 
the  user. 
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•  Line  5.  Concurrency  constraints  are  not  met.  CAPS  generates  an  alert  for  the  user. 

•  Line  6.  Network  constraints  are  not  met.  CAPS  generates  an  alert  for  the  user. 

Use  Case:  U10.  Manage  project  changes 

Actors:  User,  Project  Manager 

Type:  primary  and  essential 

Purpose:  Allow  Project  Manager  to  control  configuration  and  version  control 

for  a  project 

Overview:  User  (possibly  more  than  one)  will  submit  module(s)  to  the  Project 

Manager  for  incorporation  into  the  project  prototype.  The  user  may 
elect  to  return  the  entire  prototype  after  making  changes  to  only 
some  of  the  modules.  In  this  case  the  Project  Manager  must 
identify  which  modules  are  changed  or  new.  If  the  module  does  not 
already  exist  in  the  project  database,  the  Project  Manager  will 
merge  the  submitted  module(s)  into  one  module,  resolving  any 
conflicts.  CAPS  will  assign  and  track  a  version  number  and  insert 
the  module  into  the  project  database,  making  ties  to  all  other 
modules  that  may  exist  in  the  project  database.  If  the  module 
previously  existed  in  the  project  database,  the  Project  Manager  will 
merge  all  submitted  modules  with  the  existing  one,  resolving  any 
conflicts.  CAPS  will  update  the  version  number.  If  an  existing 
module  is  submitted  to  the  Project  Manager,  CAPS  will  verify  that 
all  other  modules  that  it  depends  on  are  the  most  up  to  date 
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version.  CAPS  will  generate  an  alert  if  there  is  an  error  in 
transmitting  a  module  and  an  acknowledgement  if  there  is  no  error. 
Cross  Reference:  Functions:  R1.19,  R1.20,  R3.1,  R3.3,  R3.4,  R3.6,  R4.3,  R4.4,  R4.6, 

R4.7,  R4.8 

Use  Cases:  Project  Manager  must  have  completed  the  Start-up, 
Log  in  and  Open  Project  use  cases 

Section:  Main 

Typical  Course  of  Action 

Actor  Action  System  Response 

1.  This  use  case  begins  with  the  2.  All  modules  submitted  for  a  project 
Project  Manager  selecting  the  option  that  are  pending  action  are  displayed 
from  a  CAPS  menu  to  review  modules 
that  have  been  submitted  for  the 
current  project 

3.  Project  Manager  determines  module 
update  state: 

a.  If  a  single  module  not  previously  in 
the  project  is  submitted,  see  section 
Single  New  Module 

b.  If  multiple  versions  of  a  module  not 
previously  in  the  project  are  submitted, 
see  section  Multiple  New  Modules 
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c.  If  a  single  module  previously  in  the 
project  is  submitted,  see  section  Single 
Old  Module 

d.  If  multiple  versions  of  a  module 
previously  in  the  project  are  submitted, 
see  section  Multiple  Old  Modules 

Alternate  Courses 

•  Line  2.  If  there  was  an  error  in  receiving  any  module,  the  Project  Manager  is  alerted 
Section:  Single  New  Module 
Typical  Course  of  Action 

Actor  Action  System  Response 

1.  The  Project  Manager  selects  the  2.  The  module  is  displayed  in  a  text 
option  to  view  the  new  module  from  a  format 
CAPS  menu 

3.  If  the  Project  Manager  decides  to  4.  The  Project  Manager  is  asked  where 
include  the  module  in  the  project,  she  to  save  the  file  and  exactly  which 
selects  the  add  option  from  a  CAPS  project  to  include  it  in 
menu 

5.  The  Project  Manager  specifies  the  6.  The  module  is  saved  and  included 
location  to  save  to  and  the  project  into  as  directed 
which  the  module  is  to  be  included 


85 


7.  The  module  will  be  assigned  a 
version  number  automatically 

8.  The  module  will  be  registered  with 
the  project  automatically 


Section:  Multiple  New  Modules 

Typical  Course  of  Action 
Actor  Action 

1.  The  Project  Manager  selects  the 
option  to  view  the  new  modules  from  a 
CAPS  menu 

3.  If  the  Project  Manager  decides  to 
include  the  modules  in  the  project,  he 
selects  the  merge  option  from  a  CAPS 
menu 

6.  The  Project  Manager  specifies  the 
location  to  save  to  and  the  project  into 
which  the  module  is  to  be  included 


System  Response 

2.  The  modules  are  displayed  in  a  text 
format  as  selected 

4.  The  Project  Manager  is  asked  which 
modules  to  merge 

5.  After  merging  the  modules  into  a 
single  prototype,  the  Project  Manager 
is  asked  where  to  save  the  file  and 
exactly  which  project  to  include  it  in 

7.  The  module  is  saved  and  included 
as  directed 

8.  The  module  will  be  assigned  a 
version  number  automatically 
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9.  The  module  will  be  registered  with 
the  project  automatically 

Alternate  Courses 

•  Line  5.  If  the  modules  cannot  be  successfully  merged  automatically,  the  Project 
Manager  is  sent  an  alert  along  with  information  about  the  conflict(s) 


Section:  Single  Old  Module 

Typical  Course  of  Action 
Actor  Action 

1.  The  Project  Manager  selects  the 
option  to  view  the  new  module  from  a 
CAPS  menu 

3.  If  the  Project  Manager  decides  to 
replace  the  existing  module  in  the 
project,  she  selects  the  merge  option 
from  a  CAPS  menu 

6.  The  Project  Manager  specifies  the 
location  to  save  to  and  the  project  into 
which  the  module  is  to  be  included 


System  Response 

2.  The  module  is  displayed  in  a  text 
format 

4.  The  Project  Manager  is  asked  to 
specify  the  modules  to  merge 

5.  After  merging  the  modules  into  a 
single  prototype,  the  Project  Manager 
is  asked  where  to  save  the  file  and 
exactly  which  project  to  include  it  in 

7.  The  module  is  saved  and  included 
as  directed 
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8.  The  module  will  be  assigned  an 
updated  version  number  automatically 


Alternate  Courses 

•  Line  3.  The  Project  Manager  can  elected  to  simply  replace  the  existing  module  with 
the  new  one 

•  Line  5.  If  the  modules  cannot  be  successfully  merged  automatically,  the  Project 
Manager  is  sent  an  alert  along  with  information  about  the  conflict(s) 


Section:  Multiple  Old  Modules 

Typical  Course  of  Action 
Actor  Action 

1.  The  Project  Manager  selects  the 
option  to  view  the  new  modules  from  a 
CAPS  menu 

3.  If  the  Project  Manager  decides  to 
include  the  modules  in  the  project,  he 
selects  the  merge  option  from  a  CAPS 
menu 


System  Response 

2.  The  modules  are  displayed  in  a  text 
format  as  selected 

4.  The  Project  Manager  is  asked  to 
specify  the  new  modules  to  merge  into 
a  single  module 

5.  After  merging  the  modules  into  a 
single  module,  the  Project  Manager  is 
asked  which  existing  module  to  merge 
with  the  single  new  module 
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7.  The  Project  Manager  specifies  the  6.  After  merging  the  modules  into  a 
location  to  save  to  and  the  project  into  single  prototype,  the  Project  Manager 
which  the  module  is  to  be  included  is  asked  where  to  save  the  file  and 

exactly  which  project  to  include  it  in 

8.  The  module  is  saved  and  included 
as  directed 

9.  The  module  will  be  assigned  an 
updated  version  number  automatically 

Alternate  Courses 

•  Line  4.  The  Project  Manager  may  elect  to  merge  the  new  modules  and  the  existing 
module  at  the  same  time 

•  Line  5.  If  the  modules  cannot  be  successfully  merged  automatically,  the  Project 
Manager  is  sent  an  alert  along  with  information  about  the  conflict(s) 

•  Line  6.  If  the  modules  cannot  be  successfully  merged  automatically,  the  Project 
Manager  is  sent  an  alert  along  with  information  about  the  conflict(s) 

Use  Case:  U1 1.  Manage  reuse  database  changes 

Actors:  User,  Software  Librarian 

Type:  primary  and  essential 

Purpose:  Allow  Software  Librarian  to  control  configuration  and  version  control 

for  the  reuse  database 
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Overview:  User  submits  a  new  module,  or  an  existing  one  that  was  modified, 

to  the  Software  Librarian.  When  the  Software  Librarian  accepts  the 
module  for  inclusion  in  the  reuse  database,  a  version  control 
number  is  assigned  or  updated  as  necessary  and  the  module  is 
saved  to  the  reuse  library.  If  the  module  was  an  update  of  an 
existing  one,  all  users  of  the  old  version  are  alerted.  The  Software 
Librarian  can  also  delete  modules. 

Cross  Reference:  Functions:  R1.22,  R1.23,  R3.1,  R3.3,  R3.4,  R3.6 

Use  Cases:  Software  Librarian  must  have  completed  the  Start-up 
and  Log  in  use  cases 

Section:  Main 

Typical  Course  of  Action 

Actor  Action  System  Response 

1.  This  use  case  begins  with  the  2.  All  modules  submitted  for  inclusion 
Software  Librarian  selecting  the  option  that  are  pending  action  are  displayed 
from  a  CAPS  menu  to  review  modules 
that  have  been  submitted  for  inclusion 
in  the  reuse  database 

3.  The  Software  Librarian  selects  the  4.  The  module  is  displayed  in  a  text 
option  to  view  the  a  module  on  the  list  format 
from  a  CAPS  menu 
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5.  After  review,  the  Software  Librarian 
selects  the  add  option  from  CAPS 
menu. 

6.  The  Software  Librarian  chooses  to 
add  the  module  as  a  new  one  or  to 
replace  an  existing  module  with  the 
new  one: 

a.  If  the  module  is  added  as  a 
completely  new  one,  see  section  Add 
New  Module 

b.  If  the  module  is  replacing  an 
existing  module,  see  section  Replace 
Existing  Module 

Section:  Add  New  Module 

Typical  Course  of  Action 

Actor  Action  System  Response 

1.  The  Software  Librarian  elects  to  add  2.  The  module  is  added  to  the  reuse 
the  submitted  module  as  a  new  module  database  and  a  version  control  number 

is  assigned 
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Section:  Replace  Existing  Module 

Typical  Course  of  Action 
Actor  Action 


System  Response 

1.  The  Software  Librarian  elects  to  2.  The  new  module  replaces  the 
replace  an  existing  module  with  the  existing  one  in  the  reuse  database 
submitted  module  3.  The  version  control  number  is 

updated 

4.  Users  of  the  old  version  are  alerted 
that  there  are  changes  to  the  module 
they  checked  out 
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APPENDIX  B:  CAPS  SERVER  IMPLEMENTATION  SOURCE  CODE 


This  appendix  contains  the  IDL  file  that  describes  the  methods  defined  in  order  to 
implement  a  distributed  CAPS  server.  It  also  contains  the  source  files  and  Javadoc 
generated  documentation  for  the  CAPS  server. 


/** 

*  The  Interface  Description  Language  (IDL)  for  a  Distributed  CAPS 

* 

*  @author  Gary  Kreeger 

*  @version  1.0 
*/ 


module  DistributedCaps 

{ 

interface  DistCaps 

{ 

exception  cantWriteFile  {}; 
exception  cantReadFile  {}; 

typedef  sequence<octet>  prototype  Jile; 
typedef  sequence<string>  prototypejist; 

string  translate  (in  prototype  Jile  psdljile,  in  string  name, 

in  string  version,  in  string  user)  raises  (cantWriteFile); 

prototypejist  get _proto Jist  (in  string  user); 

prototype  Jile  open_proto  (in  string  name,  in  string  user)  raises  (cantReadFile); 

string  commit  (in  prototype  Jile  psdljile,  in  string  name, 

in  string  version,  in  string  user)  raises  (cantWriteFile); 


}; 

}; 


*  The  DistributedCaps  Server  main  program.  It  instantiates  a  DisCapsImpl 

*  object,  starts  the  orb  and  registers  the  object  with  the  orb. 

* 

*  @author  Gary  Kreeger 

*  @ version  1.0 
*/ 
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import  DistributedCaps.*; 

import  org.omg.  CosNaming.  * ; 

import  org.omg. CosNaming.NamingContextPackage. * ; 

import  org.omg.CORBA.*; 

public  class  CapsServer 
{  static  public  void  mam(String[]  args) 
try 
{ 

//  Initialize  the  ORB 

ORB  orb  =  ORB.init(args,  null); 

//  Create  the  Caps  object 
DistCapsImpl  caps  =  new  DistCapsImpl(); 
orb.connect  (caps); 

//get  the  root  naming  context 

org.omg.CORBA.Object  objRef  =  orb.resolve_initial_references  ("NameService"); 
NamingContext  ncRef  =  NamingContextHelper.narrow  (objRef); 

//  bind  the  Object  Reference  in  Naming 

NameComponent  nc  =  new  NameComponent  ("DistCaps",  "  "); 

NameComponent  path(]  =  {nc}; 
ncRef.rebind  (path,  caps); 

//wait  for  invocations  from  client 
java.lang.Object  sync  =  new  java.lang.Object(); 
synchronized  (sync) 

{ 

sync.wait(); 

} 

} 

catch  (Exception  e) 

{ 

System.err.println  ("Error:  "  +  e); 
e.printStackTrace  (System.out); 

} 

}//end  CapsServer 
/** 

*  The  Implementation  for  the  distributed  CAPS  object. 

* 

*  @author  Gary  Kreeger 

*  @version  1 .0 
*/ 


import  DistributedCaps.*; 
import  java.io.*; 
import  java.io.File; 
import  java.util.  Vector; 

import  javax.swing.filechooser.FileSystemView; 
public  class  DistCapsImpl  extends  _DistCapsImplBase 
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{ 

/** 

*  the  constructor  for  a  distributed  CAPS  object 
*/ 

DistCapsImpl() 

{ 

superO; 

System.out.println  ("Caps  Object  Created"); 

} 


/** 

*  Translate  function  for  creating  Ada  files  from  a  PSDL  file 

* 

*  @param  psdl_file  The  PSDL  file  to  be  translated 

*  @param  name  The  name  of  the  PSDL  file 

*  @param  version  The  version  number  of  the  PSDL  file  being  translated 

*  @param  user  The  name  of  the  user  at  the  client  session 

* 

*  @retum  A  string  to  confirm  the  file  was  transfered  and  translated 

* 

*  @throws  DistributedCaps.DistCapsPackage.cantWriteFile 
*/ 

public  String  translate  (byte[]  psdl_file,  String  name,  String  version,  String  user) 
throws  DistributedCaps.DistCapsPackage.cantWriteFile 

{ 

boolean  tempBool  =  true; 

String  protoHome; 

//MTS  8/25/99 

//  added  local  variable  userHome 
String  userHome  = 

try 

{ 

String  CapsServerFiles  =  System.getProperty("CAPSJavaHome"); 
if  (CapsServerFiles  —  null)  //  CAPSJavaHome  not  set  on  command  line 
{ 

//default  to  the  home  directory 

File  homeDir  =  FileSystemView.getFileSystemView  O.getHomeDirectory  (); 
protoHome  =  new  String  (homeDir  +  File.separator  +  user  + 

File,  separator  +  ".caps"); 

//MTS  8/25/99 

//  added  code  to  initialize  userHome 
userHome  =  (homeDir '+  File.separator  +  user); 

File  protoDir  =  new  File  (protoHome); 
if  (!  protoDir.  exists  0) 

{ 

protoDir.mkdir  0; 

} 

} 

else 

{ 

protoHome  =  new  String  (CapsServerFiles  +  File.separator  +  user  + 
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File.separator  +  ".caps"); 

//MTS  8/25/99 

//  added  code  to  initialize  userHome 

userHome  =  (CapsServerFiles  +  File.separator  +  user); 

File  protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  0) 

{ 

protoDir.mkdir  0; 

} 

}  • 

//ensure  the  file  is  created,  read  the  byte  array  into  a  FileOutputStream 
//and  then  read  the  FileOutputStream  into  the  file 
String  proto  =  name; 

File  PSDL_Demo  =  new  File  (protoHome  +  File.separator  +  name  + 
File.separator  +  version  +  File.separator  +  proto  +  ".psdl"); 
tempBool  =  PSDL_Demo.createNewFile(); 

FileOutputStream  fos  =  new  FileOutputStream  (PSDL_Demo); 

fos.write  (psdl_file); 

fos.close(); 

} 

catch  (Exception  e) 

{ 

throw  new  DistributedCaps.DistCapsPackage.cantWriteFileO; 

} 

//MTS  8/25/99 

//  replace  protoHome  with  userHome  in  the  following  call  to  translate.script 
//  String  command  =  "translate.script  "  +  protoHome  +  "  "  +  name  +  "  "  +  version; 

String  command  =  "translate.script  "  +  userHome  +  "  "  +  name  +  "  "  +  version; 

try 

{ 

Runtime  run  =  Runtime.getRuntimeO; 
run.exec(command); 

} 

catch  (IOException  ex) 

{ 

System.out.println  (ex); 

}  ' 

return  "\nThe  PSDL  file  was  successfully  transferred  to  the  server\n"; 

}//end  Translate 

/** 

*  Get  the  list  of  prototypes  available  remotely 

* 

*  @param  user  The  name  of  the  user  at  the  client  session 

* 

*  @return  An  array  of  prototype  names  that  may  be  selected  for  opening 
*/ 

public  String  []  get__proto_list(String  user) 


96 


{ 

String  []  protolist; 

String  CapsServerFiles  =  System.getPropertyC’CAPSJavaHome”); 

String  protoHome; 

File  protoDir; 

if  (CapsServerFiles  ==  null)  //  CAPSJavaHome  not  set  on  command  line 

{ 

File  homeDir  =  FileSystemView.getFileSystemView  ().getHomeDirectory  (); 
protoHome  =  new  String  (homeDir  +  File,  separator  +  user  + 

File.separator  +  ".caps"); 
protoDir  ~  new  File  (protoHome); 
if  (IprotoDir.exists  ()) 

{ 

protoDir.mkdir  0; 

} 

} 

else 

{ 

protoHome  =  new  String  (CapsServerFiles  +  File.separator  +  user  + 
File.separator  +  ".caps"); 
protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  0) 

{ 

protoDir.mkdir  0; 

} 

} 

//  vector  to  hold  prototype  names 
Vector  prototypeNames  =  new  Vector  (0, 2); 

//  array  to  hold  list  of  existing  files 
File  []  dirs  =  protoDir.listFiles  0; 

if  (dirs.length  =  0)  //  no  files  exist 

{ 

return  protolist  =  new  String  [0]; 

} 

else 

{ 

for  (int  ix  =  0;  ix  <  dirs.length;  ix++) 

{ 

String  protoName  =  ""; 
protoName  =  dirs  [ixJ.getName  (); 

File  subDirs  []  =  dirs  [ixj.listFiles  0; 
for  (int  jx  =  0;  jx  <  subDirs.length;  jx++) 

{ 

prototypeNames.addElement  (protoName.concat 
(File.separator  +  subDirs  [jxJ.getName  0)); 

> 

} 

//get  the  vector  into  an  object  array  and  then  convert  it  to  a  string  array 
Object  []  temp_proto_list  =  prototypeNames.toArray  0; 
protolist  =  new  String  [temp_proto_list. length] ; 

for  (int  ix  =  0;  ix  <  temp_proto_list. length;  ix++) 
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{ 

protolist[ix]  =  String.valueOf  (temp_proto_list[ix]); 

} 

return  protolist; 

} 

}//end  get_proto_list 


/** 

*  Open  the  selected  prototype 

* 

*  @param  name  The  name  of  the  prototype  opened 

*  @param  user  The  name  of  the  user  at  the  client  session 

* 

*  @return  A  byte  array  holding  the  selected  prototype  PSDL  file 

* 

*  @throws  DistributedCaps.DistCapsPackage.cantReadFile 
*/ 

public  byte[]  open_jproto  (String  name,  String  user) 

throws  DistributedCaps.DistCapsPackagexantReadFile 

{ 

try 

{ 

byte[]  proto_file; 

String  CapsServerFiles  =  System.getPropertyC'CAPSJavaHome"); 

String  protoHome; 

File  protoDir; 

if  (CapsServerFiles  =  null)  //  CAPSJavaHome  not  set  on  command  line 

{ 

File  homeDir  =  FileSystemView.getFileSystemView  ().getHomeDirectory  (); 
protoHome  =  new  String  (homeDir  +  File.separator  +  user  + 

File.separator  +  ".caps"); 
protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  0) 

{ 

protoDir.mkdir  0; 

} 

} 

else 

{ 

protoHome  =  new  String  (CapsServerFiles  +  File.separator  +  user  + 
File.separator  +  ".caps"); 
protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  0) 

{ 

protoDir.mkdir  (); 

} 

} 

if  (name  =  null) 

{ 

return  proto_file  =  new  byte[0]; 

} 
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else 

{ 

//  create  file  object  with  which  to  manipulate  the  selected  file 
File  selectedDir  =  new  File  (protoHome  +  File.separator  +  name); 
File  file  =  new  File  (selectedDir.getAbsolutePath  ()  +  File.separator  + 
selectedDir.getParentFile  O.getName  0  +  ".psdl"); 
if  (Ifile.exists  0) 

{ 

return  proto_file  =  new  byte[0]; 

} 

else 

{ 

//read  the  opened  file  into  a  FilelnputStream  and  then  read  the 
//FilelnputStream  in  the  byte  array  to  be  returned 
FilelnputStream  in  =  new  FilelnputStream  (file); 
proto_file  =  new  byte[in.available()]; 
in-read  (proto_file); 
return  proto_file; 


} 


) 


} 

catch  (Exception  e) 
{ 


throw  new  DistributedCaps.DistCapsPackage.cantReadFileO; 

} 


}//end  open_proto 


/** 

*  Save  a  prototype's  PSDL  file  on  a  local  client  to  the  remote  server 

* 

*  @param  psdl_file  The  PSDL  file  to  be  translated 

*  @param  name  The  name  of  the  PSDL  file 

*  @param  version  The  version  number  of  the  PSDL  file  being  translated 

*  @param  user  The  name  of  the  user  at  the  client  session 

* 

*  @retum  A  string  to  confirm  the  file  was  transfered 

* 

*  @throws  DistributedCaps.DistCapsPackage.cantWriteFile 
*/ 

public  String  commit  (byte[]  psdl_file,  String  name,  String  version,  String  user) 
throws  DistributedCaps.DistCapsPackage.cantWriteFile 

{ 

boolean  tempBool  =  true; 

String  protoHome  = 

String  proto  =  name; 

String  completePath  = 

try 

{ 

String  CapsServerFiles  =  System.getProperty("CAPSJavaHome"); 
if  (CapsServerFiles  =  null)  //  CAPSJavaHome  not  set  on  command  line 
{ 
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File  homeDir  =  FileSystemView.getFileSystemView  ().getHomeDirectory  (); 

protoHome  =  (homeDir  +  File.separator  +  user  + 

File.separator  +  ".caps”); 

File  protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  0) 

{ 

protoDir  .mkdir  (); 

} 

} 

else 

protoHome  =  (CapsServerFiles  +  File.separator  +  user  + 

File.separator  +  ".caps"); 

File  protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  ()) 

{ 

tempBool  =  protoDir  .mkdirs  0; 

} 

} 

completePath  =  (protoHome  +  File.separator  +  name  +  File.separator  +  version); 
File  completeDirs  =  new  File  (completePath); 

if  (IcompleteDirs. exists  0)  H  ensure  the  correct  directory  exist  to  save  to 
{ 

tempBool  =  completeDirs.mkdirsO; 

} 

//ensure  the  file  is  created,  read  the  byte  array  into  a  FileOutput Stream 
//and  then  read  the  FileOutputStream  into  the  file 

File  PSDL_Demo  =  new  File  (completePath  +  File.separator  +  proto  +  ".psdl"); 
tempBool  “  PSDLJDemo.createNewFile(); 

FileOutputStream  fos  =  new  FileOutputStream  (PSDL  Demo); 

fos.write  (psdl_file); 

fos.close(); 

} 

catch  (Exception  e) 

{ 

System.out.println  (e); 

throw  new  DistributedCaps.DistCapsPackage.cantWriteFileO; 

> 

return  "\nThe  PSDL  file  was  successfully  transferred  to  the  server\n"; 

} 

}//end  commit 
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Class  CapsServer 

j  ava . lang . Ob j  ect 

I 

+ — CapsServer 


public  class  CapsServer 
extends  java.lang.Obj  ect 


The  DistributedCaps  Server  main  program.  It  instantiates  a  DisCapsImpl  object,  starts  the  orb  and  registers 
the  object  with  the  orb. 


Constructor  Summary 

CapsServer ( ) 


Method  Summary 

static  void 

main (j ava . lang . String [ ]  args) 

Methods  inherited  from  class  java.Iang.Object 

clone,  equals,  finalize,  getClass,  hashCode,  notify,  notifyAll,  toString,  wait, 
wait,  wait 


Constructor  Detail 


CapsServer 

public  CapsServer ( ) 


Method  Detail 


main 

public  static  void  main (java. lang. String []  args) 
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+ — org . omg . CORBA. portable . Ob jectlmpl 
I 

+ — org . omg . CORBA. Dynamiclmplementation 

I 

+ — DistributedCaps ._DistCapsImplBase 

I 

+ — DistCapsImpl 


public  class  DistCapsImpl 

extends  DistributedCaps._DistCapsImplBase 

The  Implementation  for  the  distributed  CAPS  object. 

See  Also: 

Serialized  Form 
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java. lang. St ring 

commit (byte [ ]  psdl  file,  j ava . lang . String  name, 
java. lang. String  version,  java. lang. String  user) 

Save  a  prototype's  PSDL  file  on  a  local  client  to  the  remote  server 

j  ava . lang . String [  ] 

get  proto  list (java. lang. String  user) 

Get  the  list  of  prototypes  available  remotely 

byte  [] 

open  proto ( j ava . lang . String  name,  java . lang . String  user) 

Open  the  selected  prototype 

j  ava . lang .String 

translate (byte []  psdl_file,  java . lang. String  name, 
java. lang. String  version,  j ava . lang . String  user) 

Translate  function  for  creating  ADA  files  from  a  PSDL  file 

Methods  inherited  from  class  DistributedCaps._DistCapsImplBase 

ids,  invoke  _ 
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Methods  inherited  from  class  org.omg.CORBA.portable.Objectlmpl 

_create_request ,  _create_request ,  _duplicate,  __get_delegate,  _ge t_domain  jnana gers, 
_get_interface_def ,  _get_j?olicy,  _hash,  _invoke,  _is_a ,  _is_equivalent ,  _is__local, 
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Methods  inherited  from  class  java.lang.Object 

clone,  finalize,  getClass,  notify,  notifyAll,  wait,  wait,  wait 


Method  Detail 


translate 

public  java.lang.String  translate (byte [ ]  psdl_file, 

java. lang. String  name, 
java. lang. String  version, 
java . lang. String  user) 

throws  DistributedCaps . DistCapsPackage . cantWriteFile 

Translate  function  for  creating  ADA  files  from  a  PSDL  file 

Overrides: 

translate  in  class  DistributedCaps._DistCapsImplBase 

Parameters: 

psdl_f  ile  -  The  PSDL  file  to  be  translated 
name  -  The  name  of  the  PSDL  file 

version  -  The  version  number  of  the  PSDL  file  being  translated 
user  -  The  name  of  the  user  at  the  client  session 

Returns: 

A  string  to  confirm  the  file  was  transfered  and  translated 

Throws: 

DistributedCaps.DistCapsPackage.cantWriteFile  - 


get_pr°t°_list 

public  j ava. lang. String []  get_proto_list (java . lang . String  user) 

Get  the  list  of  prototypes  available  remotely 

Overrides: 

get_proto_list  in  class  DistributedCaps._DistCapsImplBase 

Parameters: 

user  -  The  name  of  the  user  at  the  client  session 

Returns: 

An  array  of  prototype  names  that  may  be  selected  for  opening 
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°pen_prot° 

public  byte[]  open__proto  (j  ava  .  lang .  String  name, 

j ava . lang . String  user) 

throws  DistributedCaps . DistCapsPackage . cantReadFile 

Open  the  selected  prototype 

Overrides: 

open_proto  in  class  DistributedCaps._DistCapsImplBase 

Parameters: 

name  -  The  name  of  the  prototype  opened 
user  -  The  name  of  the  user  at  the  client  session 

Returns: 

A  byte  array  holding  the  selected  prototype  PSDL  file 

Throws: 

DistributedCaps.DistCapsPackage.cantReadFile  - 


commit 


public  java . lang. String  commit (byte [ ]  psdl_file, 

java . lang . String  name, 
java. lang. String  version, 
java . lang . String  user) 

throws  DistributedCaps . DistCapsPackage . cantWriteFile 

Save  a  prototype's  PSDL  file  on  a  local  client  to  the  remote  server 

Overrides: 

commit  in  class  DistributedCaps._DistCapsImplBase 

Parameters: 

psdl_file  -  The  PSDL  file  to  be  translated 
name  -  The  name  of  the  PSDL  file 

version  -  The  version  number  of  the  PSDL  file  being  translated 
user  -  The  name  of  the  user  at  the  client  session 

Returns: 

A  string  to  confirm  the  file  was  transfered 

Throws: 

DistributedCaps.DistCapsPackage.cantWriteFile  - 


Tree  Deprecated  Index  Help 

PREV  CLASS  NEXT  CLASS  FRAMES  NO  FRAMES 

SUMMARY:  INNER  |  FIELD  |  CONSTR  I  METHOD  DETAIL:  FIELD  I  CONSTR  I  METHOD 


Class 


104 


APPENDIX  C:  IDL-TO-JAVA  COMPILER  GENERATED  SOURCE  CODE 


This  appendix  contains  the  source  files  and  corresponding  Javadoc  generated 
documentation  for  the  files  created  by  the  IDL-to-Java  compiler  when  creating  the 
distributed  CAPS  server. 

/* 

*  File:  ./DISTRIBUTEDCAPS/DISTCAPSJAVA 

*  From:  DISTCAPS.IDL 

*  Date:  Wed  Aug  18  20:38:43  1999 

*  By:  idltojava  Java  IDL  1.2  Aug  18  1998  16:25:34 
*/ 

package  DistributedCaps; 
public  interface  DistCaps 

extends  org.omg.CORBA.Object,  org.omg.CORBA.portable.IDLEntity  { 

String  translate(byte[]  psdl_file,  String  name,  String  version.  String  user) 
throws  DistributedCaps.DistCapsPackage.cantWriteFile; 

String[]  get_proto_list(String  user); 
byte[]  open_proto(String  name,  String  user) 
throws  DistributedCaps.DistCapsPackage.cantReadFile; 

String  commit(byte[]  psdl_file,  String  name,  String  version,  String  user) 
throws  DistributedCaps.DistCapsPackage.cantWriteFile; 

} 


/* 

*  File:  ./DISTRIBUTEDCAPS/_DISTCAPSIMPLBASE.JAVA 

*  From:  DISTCAPS.IDL 

*  Date:  Wed  Aug  18  20:38:43  1999 

*  By:  idltojava  Java  IDL  1.2  Aug  18  1998  16:25:34 
*/ 

package  DistributedCaps; 

public  abstract  class  _DistCapsImplBase  extends  org.omg.CORBA.DynamicImplementation  implements 
DistributedCaps.DistCaps  { 

//  Constructor 

public  _DistCapsImplBaseO  { 
superO; 

} 

//  Type  strings  for  this  class  and  its  superclases 
private  static  final  String  _type_ids[]  =  { 

"IDL:DistributedCaps/DistCaps:  1.0" 

}; 


public  Stringf]  _ids()  {  return  (String[])  _type_ids.clone();  } 

private  static  java.util.Dictionaiy  _methods  =  new  java.util.Hashtable(); 
static  { 
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_methods.put("translate",  new  java.lang.lnteger(0)); 

_methods.put("get_proto_list",  new  java.  lang.Integer(  1 )); 

_methods.put("open_proto",  newjava.lang.Integer(2)); 

_methods.put("commit",  new  java.lang.Integer(3)); 

} 

//  DSI  Dispatch  call 

public  void  invoke(org.omg.CORBA.ServerRequest  r)  { 
switch  (((java.lang.Integer)  _methods.get(r.op_name())).intValueO)  { 
case  0:  //  DistributedCaps.DistCaps.translate 
{ 

org.omg.CORB  A.NVList  _list  =  _orb().createjhst(0); 
org.omg.CORBA.Any  j>sdl_file  =  _orb()create_anyO; 
jsdlJfile.type(DistributedCaps.DistCapsPackage.prototype_fileHelper.type()); 
Jist.add_value("psdl_file^_j)sdHile,  org.omg.CORBA.ARG_IN. value); 
org.omg.CORBA.Any  _name  =  _orb().create_any(); 

_name.type(org.omg.CORBA.ORB.init0.getjDrimitive_tc(org.omg.CORBA.TCKind.tk_string)); 
_list.add_value(Mname",  _name,  org.omg.CORBA.ARG_IN.value); 
org.omg.CORBA.Any  _version  =  _orb().create_any(); 
_version.type(org.omg.CORBA.ORB.init0.get_primitive_tc 
(org.omg.CORBA.TCKind.tk_string)); 

_list.add_value("version",  version,  org.omg.CORBA.ARGIN.value); 
org.omg.CORBA.Any  _user  =  _orb()create_anyO; 

_user.type(org.omg.CORBA.ORB.init0.get_primitive_tc(org.omg.CORBA.TCKind.tk_string)); 
_list.add_value("user",  _user,  org.omg.CORBA.ARG_IN.value); 
r.params(_list); 
byte[]  psdl_file; 

psdHile  =  DistributedCaps.DistCapsPackage.prototype_fileHelper.extract(jpsdl_file); 

String  name; 

name  =  _name.extract_string(); 

String  version; 

version  =  _version.extract_string(); 

String  user; 

user  =  _user.extract_stringO; 

String _ result; 

try  { 

_ result  =  this.translate(psdl_file,  name,  version,  user); 

} 

catch  (DistributedCaps.DistCapsPackage.cantWriteFile  eO)  { 
org.omg.CORBA.Any  ^except  =  _orb().create_anyO; 
DistributedCaps.DistCapsPackage.cantWriteFileHelper.insert(_except,  eO); 
r.except(_except); 
return; 

} 

org.omg.CORBA.Any _ result  =  _orb()create_anyO; 

_ result.insert_string( _ result); 

r.result( _ result); 

} 

break; 

case  l://DistributedCaps.DistCaps.get_proto_list 

{ 

org.omg.CORBA.NVList  _list  =  _orb()create_list(0); 
org.omg.CORBA.Any  _user  =  _orb0.create_any(); 

_user.type(org.omg.CORBA.ORB.init0get_primitive_tc(org.omg.CORBA.TCKind.tk_string)); 

_list.add_value("user",  _user,  org.omg.CORBA.ARG  IN.value); 

r.params(_list); 

String  user; 


106 


user  =  _user.extract_string(); 

String[] _ result; 

_ result  =  this.get__proto_list(user); 

org.omg.CORBA.Any _ result  =  _orb().create_anyO; 

DistributedCaps.DistCapsPackage.prototype_listHelper.insert( _ result, _ result); 

r.result( _ result); 

} 

break; 

case  2:  //  DistributedCaps.DistCaps.open_proto 

{ 

org.omg.CORBA.NVList  _list  =  _orb().create_list(0); 
org.omg.CORBA.Any  _name  =  _orb().create_any(); 

_name.type(org.omg.CORBA.ORB.init0.get_primitive_tc(org.omg.CORBA.TCKind.tk_string)); 
_list.add_value("name",  name,  org.omg.CORBA.ARG_IN. value); 
org.omg.CORBA.Any  _user  =  _orb().create_anyO; 

_user.type(org.omg.CORBA.ORB.init().get_primitive_tc(org.omg.CORBA.TCKind.tk_string)); 

_list.add_value("user",  _user,  org.omg.CORBA.ARG_IN.value); 

r.params(_list); 

String  name; 

name  =  _name.extract_string(); 

String  user; 

user  =  _user.extract_string(); 

byte[] _ result; 

try  { 

_ result  =  this.open_proto(name,  user); 

> 

catch  (DistributedCaps.DistCapsPackage.cantReadFile  eO)  { 
org.omg.CORBA.Any  _except  =  _orb().create_any(); 
DistributedCaps.DistCapsPackage.cantReadFileHelper.insert(_except,  eO); 
r.except(_except); 
return; 

} 

org.omg.CORBA.Any _ result  =  _orb().create_any(); 

DistributedCaps.DistCapsPackage.prototype_fileHelper.insert( _ result, _ result); 

r.result( _ result); 

} 

break; 

case  3:  //  DistributedCaps.DistCaps.commit 

{ 

org.omg.CORBA.NVList  _list  =  _orb().create_list(0); 
org.omg.CORBA.Any  _psdl_file  =  _orb() .  ere  ate_any  () ; 
_psdl_file.type(DistributedCaps.DistCapsPackage.prototype_fileHelper.type()); 
_list.add_value("psdl_file",  __psdlj51e,  org.omg.CORBA.ARG_IN.  value); 
org.omg.CORBA.Any  _name  =  _orb() .  create_any  0 ; 

_name.type(org.omg.CORBA.ORB.init0.getj3rimitive_tc(org.omg.CORBA.TCKind.tk_string)); 
_list.add_value("name",  _name,  org.omg.CORBA.ARGIN.  value); 
org.omg.CORBA.Any  _version  =  _orb().create_any(); 
_version.type(org.omg.CORBA.ORB.init().get_primitive_tc 
(org.omg.CORBA.TCKind.tk_string)); 

_list.add_value(Mversion,,?  ^version,  org.omg.CORBA.ARG_IN,value); 
org.omg.CORBA.Any  _user  =  _orb()  •  create_any  () ; 

_user.type(org.omg.CORBA.ORB.init0.get_primitive_tc(org.omg.CORBA.TCKind.tk_string)); 
Jist.addjvalueO'user",  _user,  org.omg.CORBA.ARG_IN.value); 
r.params(_list); 
byte[]  psdi_file; 

psdl_file  =  DistributedCaps.DistCapsPackage.prototype_fileHelper.extract(_psdl__file); 


107 


String  name; 

name  =  _nam  e .  extr  act_string() ; 

String  version; 

version  =  _version.extract_string(); 

String  user; 

user  =  _user.extract_string(); 

String _ result; 

tiy  { 

_ result  =  this.commit(psdl_file,  name,  version,  user); 

} 

catch  (DistributedCaps.DistCapsPackage.cantWriteFile  eO)  { 
org.omg.CORBA.Any  ^except  =  _orb().create_anyO; 
DistributedCaps.DistCapsPackage.cantWriteFileHelper.insert(_except,  eO); 
r.except(_except); 
return; 

} 

org.omg.CORBA.Any _ result  =  _orb().create_any(); 

_ result.insert_string( _ result); 

r.result( _ result); 

} 

break; 

default: 

throw  new  org.omg.CORBA.BAD_OPERATION(0, 
org.omg.CORBA.CompletionStatus.COMPLETEDMAYBE); 

} 

} 

} 


/* 

*  File:  ,/DISTRIBUTEDCAPS/_DISTCAPSSTUB.JAVA 

*  From:  DISTCAPS.IDL 

*  Date:  Wed  Aug  18  20:38:43  1999 

*  By:  idltojava  Java  IDL  1.2  Aug  18  1998  16:25:34 
*/ 

package  DistributedCaps; 
public  class  _DistCapsStub 

extends  org.omg.CORBA.portable.Objectlmpl 
implements  DistributedCaps.DistCaps  { 

public  _DistCapsStub(org.omg.CORBA.portable.Delegate  d)  { 
superO; 

_set_delegate(d); 

} 

private  static  final  String  _type_ids[]  =  { 
"IDL:DistributedCaps/DistCaps:  1 .0" 

}; 


public  String[]  _ids0  { return  (String!])  _type_ids.clone(); } 

//  IDL  operations 

//  Implementation  of  ::DistributedCaps::DistCaps::translate 

public  String  translate(byte[]  psdl_file,  String  name,  String  version,  String  user) 
throws  DistributedCaps.DistCapsPackage.cantWriteFile  { 
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org.omg.CORBA.Request  r  =  _request("translate"); 

r.set_retum_type(org.omg.CORBA.ORB.init0get_primitive_tc(org.omg.CORBA.TCKmd.tk_string)); 
org.omg.CORBA.Any  _psdl_file  =  r.add_in_arg(); 

DistributedCaps.DistCapsPackage.prototype_fileHelper.insert(_psdl_file,  psdl_file); 
org.omg.CORBA.Any  _name  =  r.add_in_argO; 

_name.insert_string(name); 
org.omg.CORBA.Any  _version  =  r.add_in_argO; 

_version.insert_string(version); 
org.omg.CORBA.Any  _user  =  r.add_in_arg(); 

_user.insert_string(user); 

r.exceptions().add(DistributedCaps.DistCapsPackage.cantWriteFileHelper.type()); 

r.invokeO; 

java.lang.Exception _ ex  =  r.env().exceptionO; 

if  ( _ ex  instanceof  org.omg.CORBA.UnknownUserException)  { 

org.omg.CORBA.UnknownUserException _ userEx  =  (org.omg.CORBA.UnknownUserException) 

if( _ userEx.except.type0.equals(DistributedCaps.DistCapsPackage.cantWriteFileHelper,type()))  { 

throw  DistributedCaps.DistCapsPackage.cantWriteFileHelper.extract(_userEx.except); 

} 

} 

String _ result; 

_ result  =  r.retum__value0.extract_stringO; 

return _ result; 

} 

//  Implementation  of : : DistributedCaps : : DistCaps : : get_proto_list 

public  Stringf]  get_proto_list(String  user) 

org.omg.CORBA.Request  r  =  _request(”get_proto_list"); 
r.set_retum_type(DistributedCaps.DistCapsPackage.prototype_listHelper.type()); 
org.omg.CORBA.Any  _user  =  r.add_in_arg(); 

_user.insert_string(user); 

r.invoke(); 

String[] _ result; 

_ result  =  DistributedCaps.DistCapsPackage.prototype_listHelper.extract(r.retum_value()); 

return _ result; 

} 

//  Implementation  of  ::DistributedCaps::DistCaps::open_proto 
public  byte[]  open _proto(String  name,  String  user) 
throws  DistributedCaps.DistCapsPackage.cantReadFile  { 
org.omg.CORBA.Request  r  =  _request("openjroto"); 
r.set_retum_type(DistributedCaps.DistCapsPackage.prototype_fileHelper.typeO); 
org.omg.CORBA.Any  name  =  r.add_in_arg(); 

_name.insert_string(name); 
org.omg.CORBA.Any  _user  =  r.add_in_arg(); 

_user.  insert_string(user); 

r.exceptions0.add(DistributedCaps.DistCapsPackage.cantReadFileHelper.typeO); 

r.invokeO; 

java.lang.Exception _ ex  =  r.envO.exceptionO; 

if  ( _ ex  instanceof  org.omg.CORBA.UnknownUserException)  { 

org.omg.CORBA.UnknownUserException _ ^userEx  =  (org.omg.CORBA.UnknownUserException) 

if  ( _ userEx.except.typeO.equals(DistributedCaps.DistCapsPackage.cantReadFileHelper.typeO))  { 

throw  DistributedCaps.DistCapsPackage.cantReadFileHelper.extract( _ userEx.except); 

> 

} 

byte[] _ result; 

_ result  =  DistributedCaps.DistCapsPackage.prototype_fxleHelper.extract(r.retum_valueO); 

return _ result; 


} 

//  Implementation  of  ::DistributedCaps::DistCaps::commit 
public  String  commit(byte[]  psdl  file,  String  name,  String  version,  String  user) 
throws  DistributedCaps.DistCapsPackage.cantWriteFile  { 
org.omg.CORBA.Request  r  =  jrequest("commit"); 

r.set_retum_type(org.omg.CORBA.ORB.init0.getjDrimitive_tc(org.omg.CORBA.TCKind.tk_string)); 
org.omg.CORBA.Any  _psdl_file  =  r.add_in_argO; 

DistributedCaps.DistCapsPackage.prototype_fileHelper.insert(_psdl_file,  psdl_file); 
org.omg.CORBA.Any  _name  =  r.add_in_arg(); 

_name.insert_string(name); 
org.omg.CORBA.Any  ^version  =  r.add_in_arg(); 

_version.insert_string(  version); 
org.omg.CORBA.Any  jiser  =  r.add_in_arg(); 

_user.insert_string(user); 

r.exceptionsO.add(DistributedCaps.DistCapsPackage.cantWriteFileHelper.typeO); 

r.invokeO; 

java.lang.Exception _ ex  =  r.env0.exception(); 

if  ( _ ex  instanceof  org.omg.CORBA.UnknownUserException)  { 

org.omg.CORBA.UnknownUserException _ userEx  =  (org.omg.CORBA.UnknownUserException) _ ex 

if( _ userEx.except.type().equaIs(DistributedCaps.DistCapsPackage.cantWriteFileHelper.type()))  { 

throw  DistributedCaps.DistCapsPackage.cantWriteFileHelper.extract( _ ^userEx.except); 

} 

} 

String _ result; 

_ result  =  r.retum_value().extract_string(); 

return _ ^result; 


}; 


/* 

*  File:  ,/DISTRIBUTEDCAPS/DISTCAPSHELPER.JAVA 

*  From:  DISTCAPS.IDL 

*  Date:  Wed  Aug  18  20:38:43  1999 

*  By:  idltojava  Java  IDL  1.2  Aug  18  1998  16:25:34 
*/ 

package  DistributedCaps; 
public  class  DistCapsHelper  { 

//  It  is  useless  to  have  instances  of  this  class 
private  DistCapsHelperO  { } 

public  static  void  write(org.omg.CORBA.portable.OutputStream  out,  DistributedCaps.DistCaps  that)  { 
out.write_Object(that); 

} 

public  static  DistributedCaps.DistCaps  read(org.omg.CORBA.portable.InputStream  in)  { 
return  DistributedCaps.DistCapsHelper.narrow(in.read_Object0); 

} 

public  static  DistributedCaps.DistCaps  extract(org.omg.CORBA.Any  a)  { 
org.omg.CORBA.portable.InputStream  in  =  a.create_input_stream(); 
return  read(in); 

} 

public  static  void  insert(org.omg.CORBA.Any  a,  DistributedCaps.DistCaps  that)  { 
org.omg.CORBA.portable.OutputStream  out  =  a.create_output_stream(); 
write(out,  that); 


110 


a.read_value(out.create_input_stream(),  type()); 

} 

private  static  org.omg.CORBA.TypeCode  _tc; 
synchronized  public  static  org.omg.CORBA.TypeCode  type()  { 
if  (_tc  =  null) 

_tc  =  org.omg.CORBA.ORB.init0.create_interface_tc(id(),  "DistCaps"); 
return  _tc; 

} 

public  static  String  id()  { 
return  "IDL:DistributedCaps/DistCaps:  1 .0"; 

} 

public  static  DistributedCaps.DistCaps  narrow(org.omg.CORBA.Object  that) 
throws  org.omg.CORBA.BAD_PARAM  { 
if  (that  —  null) 
return  null; 

if  (that  instanceof  DistributedCaps.DistCaps) 
return  (DistributedCaps.DistCaps)  that; 
if  (!that._is_a(id()))  { 

throw  new  org.omg.CORBA.BAD_PARAM(); 

} 

org.omg.CORBA.portable.Delegate  dup  =  ((org.omg.CORBA.portable.ObjectImpl)that)._get_delegate(); 
DistributedCaps.DistCaps  result  =  new  DistributedCaps.  DistCapsStub(dup); 
return  result; 

} 

} 


/* 

*  File:  ./DISTRIBUTEDCAPS/DISTCAPSHOLDER.JAVA 

*  From:  DISTCAPS.IDL 

*  Date:  Wed  Aug  18  20:38:43  1999 

*  By:  idltojava  Java  IDL  1.2  Aug  18  1998  16:25:34 
*/ 

package  DistributedCaps; 
public  final  class  DistCapsHolder 

implements  org.omg.CORB  A.portable.Streamable  { 

//  instance  variable 

public  DistributedCaps.DistCaps  value; 

//  constructors 

public  DistCapsHolder()  { 
this(null); 

} 

public  DistCapsHolder(DistributedCaps.DistCaps  _arg)  { 
value  = _ arg; 

} 

public  void  _write(org.omg.CORBA.portable.OutputStream  out)  { 
DistributedCaps.DistCapsHelper.write(out,  value); 

} 

public  void  _read(org.omg.CORBA.portable.InputStream  in)  { 
value  =  DistributedCaps.DistCapsHelper.read(in); 

} 

public  org.omg.CORBA.TypeCode  _type()  { 


111 


return  DistributedCaps.DistCapsHelper.typeO; 

} 

} 
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DistributedCaps 

Interface  DistCaps 

All  Known  Implementing  Classes: 

DistCapsImplBase,  DistCapsStub 


public  interface  DistCaps 

extends  org.omg.CORBA.Object,  org.omg.CORBA.portable.IDLEntity 


! 

Method  Summary 

j  ava . lang . String 

commit (byte [ ]  psdl  file,  j ava . lang . String  name, 
j ava . lang. String  version,  j ava . lang . String  user) 

j  ava . lang . String [ ] 
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byte [ ] 
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java . lang. String 

translate (byte [ ]  psdl  file,  j ava . lang . String  name, 
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_ _ _ _ _ i 

Methods  inherited  from  interface  org.omg.CORBA.Object 

__create__request ,  __create_request ,  _duplicate,  _get_domain_managers, 
_get__interface_def ,  _get__policy,  _hash,  _is_a,  _is_equivalent ,  _non_existent , 
_release,  _request ,  _set  jpolicy_override 


Method  Detail 


translate 

public  j  ava .  lang .  String  translate  (byte  [  ]  psdl__file, 

java. lang. String  name, 
java. lang. String  version, 
java . lang. String  user) 

throws  DistributedCaps . DistCapsPackage . cantWriteFile 
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public  java . lang . String [ ]  get_proto_list ( j ava . lang . String  user) 


Open_Pr°t° 

public  byte[]  openjproto (j ava . lang . String  name, 

java. lang. String  user) 

throws  DistributedCaps . DistCapsPackage . cantReadFile 


commit 

public  java. lang. String  commit (byte [ ]  psdl_file, 

java. lang. String  name, 
java. lang. String  version, 
java. lang. String  user) 

throws  DistributedCaps . DistCapsPackage . cantWriteFile 
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DistributedCaps 

Class  DistCapsImplBase 

j ava . lang . Ob j ect 

I 

+--org . omg . CORBA . portable . Ob j  ect Impl 

I 

+ — org . omg . CORBA. Dynamiclmplementat ion 

I 

+- -DistributedCaps  .^DistCapsImplBase 


public  abstract  class  _DistCapsImplBase 
extends  org.omg.CORBA.DynamicImplementation 
implements  DistCaps 

See  Also: 

Serialized  Form 


Constructor  Summary 

DistCapsImplBase ( ) 


j 

Method  Summary 

j  ava .lang . String [ ] 

ids  ( ) 

1 

j 

void 

invoke (org. omg. CORBA. ServerRequest  r) 

! 

Methods  inherited  from  class  org.omg.CORBA.portabIe.ObjectImpl 

_create_reques t ,  _creat e_request ,  _duplicate ,  _get_delegate ,  __get_domain_managers , 
_get_interface_def ,  _get_policy,  _hash,  ^invoke,  _is_a,  _is_equivalent ,  _is_local, 
_non_existent ,  _orb,  _release,  _releaseReply,  ^request,  __request, 

_servant_post invoke,  _servant_j?reinvoke,  _set_delegate,  __set_policy_override, 
equals,  hashCode,  toString 


Methods  inherited  from  class  javadang.Object 

clone,  finalize,  getClass,  notify,  notifyAll,  wait,  wait,  wait 
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_DistCapsImplBase 

public  _DistCapsImplBase ( ) 

Method  Detail  _ 

_ids 

public  java . lang. String [ ]  _ids ( ) 

Overrides: 

_ids  in  class  org.omg.CORBA.portable.Objectlmpl 


invoke 


public  void  invoke (org. omg. CORBA. ServerRequest  r) 

Overrides: 

invoke  in  class  org.omg.CORBA.DynamicImplementation 
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PREV  CLASS  NEXT  CLASS  FRAMES  NO  FRAMES 
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DistributedCaps 

Class  DistCapsStub 

j  ava . lang . Ob j  ect 

I 

+  --org . omg . CORBA. portable . Ob j  ectlmpl 

I 

+ — DistributedCaps  .^DistCapsStub 


public  class  _DistCapsStub 

extends  org.omg.CORBA.portable.Objectlmpl 

implements  DistCaps 

See  Also: 

Serialized  Form 


Constructor  Summary 

DistCapsStub ( org . omg . CORBA .portable . Delegate  d) 


Method  Summary 

j  ava . lang .String [ ] 

ids  () 

java. lang. String 

commit  (byte  [  ]  psdl  file,  iava.  lang.  String  name, 
java. lang. String  version,  j ava . lang . String  user) 

j  ava . lang . String [ ] 

get  proto  list  (java .  lang.  Strincr  user) 

byte [ ] 

open  proto (java. lang. String  name,  j ava . lang . String  user) 

java . lang . String 

translate (byte [ ]  psdl  file,  i ava . lang . String  name, 
java. lang. String  version,  java . lang . String  user) 
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Methods  inherited  from  class  org.omg.CORBA.portable.Objectlmpl 

_create_request ,  _create_request ,  ^duplicate,  _get_de legate, 

_get_domain_managers,  _get_interface_def ,  _getj?olicy,  __hash,  _invoke,  _is_a, 
__is_equivalent,  _is_local,  _non__exi  stent ,  _orb,  ^release,  _releaseReply, 
^request ,  __reques  t ,  _servant_post invoke ,  ^servant  jpre invoke ,  __set_delegate , 
_set_policy_override,  equals,  hashCode,  toString 


Methods  inherited  from  class  java.Iang.Object 

clone,  finalize,  getClass,  notify,  notifyAll,  wait,  wait,  wait 
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_DistCapsStub 

public  _DistCapsStub(org.omg.C0R3A. portable.  Delegate  d) 


Method  Detail 


_ids 

public  java. lang. String []  _ids ( ) 

Overrides: 

_ids  in  class  org.omg.CORBA.portable.Objectlmpl 


translate 

public  java. lang. String  translate (byte []  psdl_file, 

java . lang. String  name, 
java. lang. String  version, 
java . lang. String  user) 

throws  DistributedCaps . DistCapsPackage . cantWriteFile 


Specified  by: 

translate  in  interface  DistCaps 


getprotolist 

public  java . lang . String [ ]  get_proto_list (java . lang. String  user) 

Specified  by: 

get  jproto  list  in  interface  Di;  .Caps 
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public  byte[]  open_proto (java . lang. String  name, 

java . lang. String  user) 

throws  DistributedCaps . DistCapsPackage . cantReadFile 


Specified  by: 

open  proto  in  interface  DistCaps 


commit 

public  java . lang . String  commit (byte [ ]  psdl__file, 

java. lang. String  name, 
j ava . lang . String  version, 
java . lang. String  user) 

throws  DistributedCaps . DistCapsPackage . cantWriteFile 


Specified  by: 

commit  in  interface  DistCaps 
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DistributedCaps 

Class  DistCapsHelper 

j  ava . lang . Ob j  ect 

I 

+ --DistributedCaps .DistCapsHelper 


public  class  DistCapsHelper 
extends  java.lang.Object 


Method  Summary 
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J 

Methods  inherited  from  class  java.lang.Object 

clone,  equals,  finalize,  getClass,  hashCode,  notify,  notifyAll,  toString,  wait, 
wait,  wait 
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write 
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public  static  void  write (org . omg . CORBA. portable . OutputSt ream  out, 

DistCaps  that) 


read 


public  static  DisrCaps  read (org. omg. CORBA. portable. Input Stream  in) 


extract 


public  static  DistCaps  extract (org . omg . CORBA. Any  a) 


insert 


public  static  void  insert (org. omg. CORBA. Any  a, 

DistCaps  that) 


type 

public  static  org. omg . CORBA. TypeCode  type ( ) 


id 


public  static  j ava . lang . String  id() 


narrow 

public  static  DistCaps  narrow (org. omg. CORBA. Object  that) 

throws  org . omg . CORBA . BAD_PARAM 
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SUMMARY:  INNER  |  FIELD  |  CONSTR  |  METHOD  DETAIL:  FIELD  |  CONSTR  |  METHOD 


DistributedCaps 

Class  DistCapsHolder 

j  ava . lang . Ob j ect 

I 

+  - -DistributedCaps . Di s  tCapsHolder 


public  final  class  DistCapsHolder 
extends  j  ava.  lang .  Obj  ect 

implements  org.omg.CORBA.portable.Streamable 


Field  Summary 


DistCaps 


value 


Constructor  Summary 

DistCapsHolder ( ) 


DistCapsHolder ( DistCaps  arg) 


Method  Summary 

void 

read (org . omg . CORBA. portable . InputStream  in) 

org . omg . CORBA . TypeCode 

type ( ) 

void 

write (org. omg . CORBA. portable . OutputStream  out) 
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APPENDIX  D:  MODIFIED  HSI  SOURCE  CODE 


This  appendix  contains  the  HSI  source  files  that  were  modified  from  [DURA99] 
and  the  corresponding  Javadoc  generated  documentation.  Changes  from  the  original 
source  code  are  bolded. 

/** 

*  The  main  CAPS  window. 

* 

*  @author  Ilker  DURANLIOGLU,  modified  by  Gary  Kreeger 

*  @version  1.1 
*/ 

package  caps.CAPSMain; 

importjava.awt.*; 
import  javax.swing.  * ; 
import  java.io.File; 
import  caps.Builder.PsdlBuilder; 
import  caps.Psdl.Vertex; 
import  caps.Psdl.DataTypes; 
import  caps.GraphEditor.Editor; 
import  java.awt.event.  * ; 
import  java.util.Vector; 
import  java.util.Enumeration; 
import  DistributedCaps.*; 

public  class  CAPSMainWindow  extends  JFrame  { 

/** 

*  The  width  of  the  frame. 

*/ 

private  final  int  WIDTH  =  400; 


/** 

*  The  height  of  the  frame. 

*/ 

private  final  int  HEIGHT  =  150; 

/** 

*  The  File  that  contains  the  PSDL  prototype. 
*/ 

private  File  prototype; 
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jkk 

*  The  object  reference  to  the  CAPS  server. 

*/ 

private  DistCaps  capsRef; 

/** 

*  The  Vector  that  holds  references  to  the  open  prototypes 

V 

private  static  Vector  openPrototypes; 


//THE  FOLLOWING  ATTRIBUTES  WERE  SUGGESTED  BY  PROFESSOR  SHING 

/** 

*  The  private  attribute  for  holding  protoName. 

*/ 

private  static  String  protoName; 

j-k-k 

*  The  private  attribute  for  holding  protoVersion. 

*/ 

private  static  String  protoVersion; 

/** 

*  The  private  attribute  for  holding  capsUser. 

*/ 

private  static  String  capsUser; 

/** 

*  The  constructor  for  this  class. 

* 

*  @param  objRef  The  reference  to  the  CAPS  object  on  the  server 
*/ 

public  CAPSMainWindow  (DistCaps  objRef) 

{ 

super  ("HSI  Designer  Mode");  //  The  title  of  the  frame, 

prototype  =  null; 

capsRef  =  objRef;  //reference  to  server  object 

capsUser  =  System.getProperty("CAPSUser");  //  session  user 

openPrototypes  =  new  Vector  (0,  2); 
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initialize  0; 


} 


/** 

*  Initializes  the  CAPS  main  window. 

*/ 

public  void  initialize  () 

{ 

setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE); 
addWindowListener  (new  ExitCAPSMain  (this)); 

//Places  the  frame  in  the  upper-right  comer  of  the  screen 

Dimension  screenSize  =  Toolkit.getDefaultToolkit().getScreenSize(); 
setLocation(screenSize. width  -  (WIDTH  +  WIDTH  /  2),  HEIGHT  /  2); 

setResizable  (false); 

setJMenuBar  (new  CAPSMainMenuBar  (this)); 

JPanel  panel  =  new  JPanel  0; 

JLabel  capsLabel  =  new  JLabel  ("Heterogeneous  System  Integrator"); 
capsLabel.setFont  (new  Font  ("Courier",  FontBOLD,  17)); 

JLabel  imageLabel  =  new  JLabel  (new  Imagelcon  ("caps/Images/caps.gif ’)); 

panel.add  (Box.createHorizontalStrut  (5)); 

panel.add  (imageLabel); 

panel.add  (Box.createHorizontalStrut  (5)); 

panel.add  (capsLabel); 

panel.add  (Box.createHorizontalStrut  (5)); 

getContentPane  ().add  (panel); 

pack  (); 

setVisible  (true); 

} 


/** 

*  Sets  the  prototype  file  to  the  argument. 

* 

*  @param  f  The  File  that  contains  the  PSDL  prototype. 
*/ 

public  void  setPrototype  (File  f) 

{ 

prototype  =  f; 

} 
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j ** 

*  Sets  the  label  to  the  string  message  passed  in. 

* 

*  @param  msg  The  message  to  be  displayed. 

*/ 


public  void  setLabel  (String  msg) 
{ 


} 


JOptionPane.showMessageDialog  (this,  msg,  "Information  Message", 
JOptionPane.INFORMATION_MESSAGE); 


/** 

*  Retrieves  the  curent  prototype  file. 

* 

*  @retum  the  File  that  contains  the  PSDL  prototype. 
*/ 

public  File  getPrototype  0 

{ 

return  prototype; 

} 


/** 

*  Retrieves  the  curent  reference  to  the  caps  server. 

* 

*  @return  the  reference  to  the  caps  server  object. 

*/ 

public  DistCaps  getCapsRef  0 

{ 

return  capsRef; 

} 

/** 

*  Returns  the  vector  that  holds  the  open  prototype  files. 

* 

*  @retum  the  vector  that  contains  the  open  prototype  files. 
*/ 

public  Vector  getOpenPrototypes  0 

{ 

return  openPrototypes; 

} 


I** 

*  Sets  the  prototype  name  to  the  argument 

* 

*  @param  name  The  string  that  contains  the  prototype's  name 

*/ 

public  void  setProtoName  (String  name) 
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{ 

protoName  =  name; 

} 


j * * 

*  Sets  the  prototype  version  to  the  argument 

* 

*  @param  version  The  string  that  contains  the  prototype's  version 

*/ 

public  void  setProtoVersion  (String  version) 

{ 

protoVersion  =  version; 

} 


*  Gets  the  prototype  name 

* 

*/ 

public  String  getProtoName  0 

{ 

return  protoName; 

} 


/** 

*  Gets  the  prototype  version 

* 

*/ 

public  String  getProtoVersion  0 

{ 

return  protoVersion; 

> 

J*-k 

*  Gets  the  capsUser 

* 

*/ 

public  String  getCapsUser  0 

t 

return  capsUser; 

} 


/** 

*  Opens  the  graphics  editor  to  edit  a  prototype. 

*/• 

public  void  editPrototype  0 

{ 

if  (prototype  =  null)  {  //  No  prototype  is  selected  to  open 

JOptionPane.showMessageDialog  (this,  "No  prototype  is  selected  to  edit.". 
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"Error  Message",  JOptionPane.ERRORMESSAGE); 

} 

else  if  (lisPrototypeChanged  0)  {  //  Attempt  to  edit  the  same  prototype. 

JOptionPane.showMessageDialog  (this,  new  String  ("Prototype  "  +  prototype.getName  ()  + 
"  is  already  open."), 

"Error  Message",  JOptionPane.ERROR_MESSAGE); 

} 

else  { 

PsdlBuilder.disable_tracing  0;  //  Disable  debug  messages 

Vertex  root  =  null; 

root  =  PsdlBuilder.buildPrototype  (prototype); 
if  (root  ==  null)  { 

root  =  new  Vertex  (0,  0,  null,  false);  //  If  this  is  a  new  prototype 
String  name  =  prototype.getName  ();  //  Prototype  name  is  the  same  as 
root.setLabel  (name.substring  (0,  name.length  0  -  5));  //  the  file  name 

} 

DataTypes  types  =  new  DataTypes  (); 
types.buildTypes  (prototype); 

Editor  e  =  new  Editor  (prototype,  root,  types); 
new  Thread  (e).start  (); 
openPrototypes.addElement  (e); 

} 

} 


/** 

*  Checks  whether  or  not  the  current  prototype  file  is  already  used  by 

*  a  PSDL  Editor. 

* 

*  @retum  true  if  selected  prototype  is  not  already  open 

* 

* / 

public  boolean  isPrototypeChanged  0 

{ 

for  (Enumeration  enum  -  openPrototypes.elements  ();  enum.hasMoreElements  ();)  { 
Editor  e  =  (Editor)  enum.nextElement  0; 
if  (prototype.equals  (e.getPrototypeFile  ())) 
return  false; 

} 

return  true; 

> 


/** 

*  Removes  one  element  from  the  openPrototypes  vector. 

* 

*  @param  e  the  editor  that  is  going  to  be  removed  from  the  vector. 
*/ 

public  static  void  removeEditor  (Editor  e) 

{ 

openPrototypes.removeElement  (e); 

} 


/** 
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*  Checks  if  the  status  of  any  of  the  open  prototypes  is  'saveRequired'. 

*  Prompts  the  user  to  save  the  prototype. 

* 

*  @retum  true  if  none  of  the  prototypes  need  saving. 

*/ 

public  boolean  isOpenPrototypeSaved  0 

{ 

boolean  flag  =  true; 

Editor  e; 
label : 

for  (Enumeration  enum  =  openPrototypes. elements  0;enum.hasMoreElements  ();)  { 
e  -  (Editor)  enum.nextElement  0; 
if  (e.isSaveRequired  0)  { 

int  ix  =  JOptionPane.showConfirmDialog  (this,  new  String  ("Save  changes  to  the  prototype  "  + 
e.getRoot  ().getLabel  ()  +  "?")); 
if  (ix  ==  JOptionPane.CANCEL_OPTION)  { 
flag  =  false; 
break  label; 

} 

else  if  (ix  =  JOptionPane.YES_OPTION) 
e.savePrototype  (); 

} 

} 

return  flag; 

} 

}  //  End  of  the  class  CAPSMainWindow 


/** 

*  This  class  holds  the  'Exec  Support'  menu  items. 

* 

*  @author  Ilker  DURANLIOGLU,  modified  by  Gary  Kreeger 

*  *  W 

*  ©version  1.1 
*/ 

package  caps.CAPSMain; 

import  javax.swing.  JMenu; 
import  javax.swing.  JMenuItem; 
import  java.awt.event.  ActionEvent; 
import  java.awt.event.  ActionListener; 
import  java.awt.*; 
import  j  ava.  io.IOException; 
import  javax.swing.*; 
import  java.io.*; 
import  DistributedCaps.*; 

public  class  ExecSupportMenu  extends  JMenu  implements  ActionListener  { 
/** 

*  Initiates  the  'Translate'  event 
*/ 

private  JMenuItem  translateMenuItem  =  new  JMenuItem  ("Translate"); 


131 


/** 

*  Initiates  the  'Schedule1  event 
*/ 

private  JMenuItem  scheduleMenuItem  =  new  JMenuItem  ("Schedule"); 
/** 

*  Initiates  the  'Compile'  event 
*/ 

private  JMenuItem  compileMenuItem  -  new  JMenuItem  ("Compile"); 
/** 

*  Initiates  the  'Execute'  event 
*/ 

private  JMenuItem  executeMenuItem  =  new  JMenuItem  ("Execute"); 
/** 

*  The  main  window  which  owns  this  menu. 

*/ 

protected  CAPSMainWindow  ownerWindow; 


/** 

*  Constructor  for  this  class. 

* 

*  @param  owner  CAPSMainWindow  that  owns  the  menu 
V 

public  ExecSupportMenu  (CAPSMainWindow  owner) 

{ 

super  ("Exec  Support"); 

ownerWindow  =  owner; 

add  (translateMenuItem); 
add  (scheduleMenuItem); 
add  (compileMenuItem); 
add  (executeMenuItem); 


//Register  the  action  listeners 

translateMenuItem.addActionListener  (this); 
scheduleMenuItem.addActionListener  (this); 
compileMenuItem.addActionListener  (this); 
executeMenuItem.addActionListener  (this); 

}  //  end  of  ExecSupportMenu  constructor 

/** 

*  Action  event  handler  for  the  menu  events. 

* 

*  @param  e  The  action  event  that  is  created  by  selecting  a  menu  item 
*/ 

public  void  actionPerformed(ActionEvent  e) 

{ 
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if  (e.getSource  0  =  translateMenuItem)  { 

if  (ownerWindow.getPrototypeO  —  null)  //  No  prototype  is  selected  to  open 

{ 

JOptionPane.showMessageDialog(ownerWindow, 

"No  prototype  is  selected  to  edit.",  "Error  Message",  JOptionPane.ERROR_MESSAGE); 

} 

else 

{ 

try 

{ 

File  proto  =  ownerWindow.getPrototypeO; 

FilelnputStream  in  =  new  FilelnputStream  (proto); 
byte[]  fileBuf  =  new  byte[in.availableO]; 
in.read  (fileBuf); 

DistCaps  capsRef  =  ownerWindow.getCapsRefO; 

String  returnMsg  =  capsRef.translate(fileBuf,  ownerWindow.getProtoNameO, 
ownerWindow.getProtoVersionO,  ownerWindow.getCapsUserO); 

ownerWindow.setLabel  (returnMsg); 

System.outprintln  (returnMsg); 


} 

catch  (Exception  el) 

{ 

System.err.println  ("Error:  "  +  el); 
el.printStackTrace  (System.out); 

} 


} 

} 

else  if  (e.getSource  0  =  scheduleMenuItem)  { 
System.outprintln  ("Schedule  has  not  been  implemented  yet"); 

} 

else  if  (e.getSource  0  —  compileMenuItem)  { 

System.out.println  ("Compile  has  not  been  implemented  yet"); 

} 

else  if  (e.getSource  0  =  executeMenuItem)  { 

System.outprintln  ("Executing  telnet"); 
try  { 

Runtime  run  =  Runtime.getRuntime  0; 
run.exec  ("telnetexe"); 

}  catch  (IOException  ex)  { 

System.out.println  (ex); 

} 

} 

}//  end  of  actionPerformed 
}  //  End  of  the  class  ExecSupportMenu 
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/** 

*  This  class  holds  the  'Prototype’  menu  items. 

* 

*  @author  Ilker  DURANLIOGLU,  modified  by  Gary  Kreeger 

* 

*  @version  1.1 
*/ 

package  caps.CAPSMain; 
import  j  avax.  swing.  * ; 

import  javax.swing.filechooser.FileSystemView; 

import  java.awt.*; 

import  j  ava.awt. event.  ActionEvent; 

import  java.awt.event.ActionListener; 

import  java.io.File; 

import  java.io.*; 

import  j  ava.util.  Vector; 

import  DistributedCaps.*; 

public  class  PrototypeMenu  extends  JMenu  implements  ActionListener  { 
/** 

*  Initiates  the  ’New'  event 
*/ 

private  JMenuItem  newMenuItem  =  new  JMenuItem  ("New”); 


*  Initiates  the  ’Open’  event 
*/ 

private  JMenuItem  openMenuItem  =  new  JMenuItem  (’’Open"); 

/** 

*  Initiates  the  'Commit  Work'  event 
*/ 

private  JMenuItem  commitWorkMenuItem  =  new  JMenuItem  ("Commit  Work"); 

/** 

*  Initiates  the  'Retrieve  From  DDB'  event 
*/ 

private  JMenuItem  retrieveMenuItem  =  new  JMenuItem  ("Retrieve  From  DDB"); 

/** 

*  Initiates  the  'Quit'  event 
V 

private  JMenuItem  quitMenuItem  =  new  JMenuItem  ("Quit"); 


134 


/** 

*  The  main  window  which  owns  this  menu. 

*/ 

protected  CAPSMainWindow  ownerWindow; 


/** 

*  Constructor  for  this  class. 

* 

*  @param  owner  The  main  window  which  has  created  this  menu. 
*/ 

public  PrototypeMenu  (CAPSMainWindow  owner) 

{ 

super  ("Prototype"); 

ownerWindow  =  owner; 

add  (newMenuItem); 
add  (openMenuItem); 
add  (commitWorkMenuItem); 
add  (retrieveMenuItem); 
add  (quitMenuItem); 

//Register  the  action  listeners 

newMenuItem.addActionListener  (this); 
openMenuItem.addActionListener  (this); 
commitWorkMenuItem.addActionListener  (this); 
retrieveMenuItem.addActionListener  (this); 
quitMenuItem.addActionListener  (this); 

}  //  end  PrototypeMenu  constructor 


/** 

*  Action  event  handler  for  the  menu  events. 

* 

*  @param  e  The  action  event  that  is  created  by  selecting  a  menu  item  from  this  menu 
*/ 

public  void  actionPerformed(ActionEvent  e) 

{ 

if  (e.getSource  0  =  newMenuItem)  { 
processNewMenuItem  0; 

} 

else  if  (e.getSource  ()  =  openMenuItem)  { 
processOpenMenuItem  (); 

} 

else  if  (e.getSource  0  —  commitWorkMenuItem)  { 
processCommitWorkMenuItem(); 

> 

else  if  (e.getSource  0  —  retrieveMenuItem)  { 

System.out.println  ("Retrieve  has  not  yet  been  implemented"); 
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} 

else  if  (e.getSource  0  =  quitMenuItem)  { 

//  Exit  the  program  if  all  of  the  prototypes  are  saved, 
if  (ownerWindow.isOpenPrototypeSaved  0) 
System.exit  (0); 

} 

}  //end  of  actionPerformed 


/** 

*  Handles  the  event  which  is  caused  by  selecting  the  *New'  menu  item. 

*/ 

public  void  processNewMenuItem  0 

{ 

//  The  system  property  for  the  home  prototype  directory. 

String  protoHome  =  System.getProperty  ("PROTOTYPEHOME"); 

File  protoDir; 

if  (protoHome  =  null)  {  //  If  it  is  not  set  as  a  command  line  argument 

File  homeDir  =  FileSystemView.getFileSystemView  ().getHomeDirectory  (); 
protoHome  =  new  String  (homeDir  +  File.separator  +  ".caps"); 
protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  ()) 
protoDir.mkdir  0; 

} 

else  { 

protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  ()) 
protoDir.mkdir  (); 

} 

String  proto  =  JOptionPane.showInputDialog  (ownerWindow, 

"Enter  Prototype  Name  :  ",  "New",  JOptionPane.PLAIN_MESSAGE); 
if  (proto  =  null) 
return; 

String  version  =  JOptionPane.showInputDialog  (ownerWindow, 

"Prototype  Version  Information  :  ","New",  JOptionPane.PLAIN_MESSAGE); 

{ 

String  name  =  proto; 

File  file  =  new  File  (protoHome  +  File.separator  +  proto  +  File.separator  +  version  + 

File.separator  +  name  +  ".psdl"); 
if  (file.exists  0)  { 

int  selected  =  JOptionPane.showConfirmDialog  (ownerWindow,  "Selected  prototype  file  already  exists.\n"  + 

"Do  you  want  to  overwrite  it  ?"); 
if  (selected  —  JOptionPane.YES_OPTION)  { 
try  { 

file.delete  0; 
file.createNewFile  0; 

}  catch  (java.io.IOException  ex)  { 

System.out.println  (ex); 

} 

ownerWindow.setPrototype  (file); 

} 

} 
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} 


else  { 
fry  { 


File  dir  =  file.getParentFile  ().getParentFile  0; 
dir.mkdir  0; 

File  vers  =  file.getParentFile  (); 
vers.mkdir  0; 
file.createNewFile  0; 

}  catch  (java.io.IOException  ex)  { 
System.outprintln  (ex); 

} 

ownerWindow.setPrototype  (file); 
ownerWindow.setProtoName  (proto); 
ownerWindow.setProtoVersion  (version); 

} 

} 

//  end  of  processNewMenuItem 


/** 

*  Handles  the  event  which  is  caused  by  selecting  the  'Open'  menu  item. 

*/ 

public  void  processOpenMenuItem  0 

{ 

Objectf]  possibleValues  =  {  "Local",  "Remote"}; 

String  selectedValue  =  (String)  JOptionPane.showInputDialog(null, 

"Please  choose  the  prototype  source",  "Input", 

JOptionPane.INFORMATION_MESSAGE,  null,  possibleValues,  possibleValuesfO]); 

if  (selectedValue  ==  "Local") 

{ 

String  protoHome  =  System.getProperty  ("PROTOTYPEHOME"); 

File  protoDir; 

if  (protoHome  =  null)  //  If  it  is  not  set  as  a  command  line  argument 

{ 

File  homeDir  =  FileSystemView.getFileSystemView  O.getHomeDirectory  (); 
protoHome  =  new  String  (homeDir  +  File.separator  +  ".caps"); 
protoDir  =  new  File  (protoHome); 
if  (!  protoDir.  exists  0) 

{ 

protoDir  .mkdir  0; 

} 

} 

else 

{ 

protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  0) 
protoDir.mkdir  0; 

} 

Vector  prototypeNames  =  new  Vector  (0, 2); 

File  []  dirs  =  protoDir.listFiles  0; 

String  protoName  =  ""; 


if  (dirs.length  =  0) 

{ 
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JOptionPane.showMessageDialog  (ownerWindow,  "No  prototype  is  is  found  to  open", 

"Error  Message",  JOptionPane.ERROR_MESSAGE); 

} 

else 

{ 

for  (int  ix  =  0;  ix  <  dirs.length;  ix++) 

{ 

protoName  =  dirs  [ix].getName  0; 

File  subDirs  []  =  dirs  [ix].listFiles  0; 
for  (int  jx  =  0;  jx  <  subDirs.length;  jx++) 

{ 

prototypeNames.addElement  (protoName.concat 
(File.separator  +  subDirs  [jx].getName  ())); 

} 

} 

} 

Object  []  protos  =  prototypeNames.toArray  (); 

String  selected  =  (String)  JOptionPane.showInputDialog  (ownerWindow,  "Select  a  protoype  : ", 
"Open",  JOptionPane.INFORMATION_MESSAGE,  null,  protos,  protos  [0]); 

if  (selected  !=  null) 

{ 

File  selectedDir  =  new  File  (protoHome  +  File.separator  +  selected); 

File  file  =  new  File  (selectedDir.getAbsolutePath  ()  +  File.separator  + 
selectedDir.getParentFile  ().getName  ()  +  ".psdl"); 
if  (Ifile.exists  0) 

{ 

JOptionPane.showMessageDialog  (ownerWindow, 

"The  selected  prototype  file  cannot  be  opened", 

"Error  Message",  JOptionPane.ERRORMESSAGE); 

} 

ownerWindow.setPrototype  (file); 

ownerWindow.setProtoName  (selectedDir.getParentFile  ().getName  ()); 
ownerWindow.setProtoVersion  (selectedDir.getName  ()); 

} 

} 

else  //  open  prototype  from  remote  source 

{ 

DistCaps  capsRef  =  ownerWindow.getCapsRefO; 

//get  the  list  of  available  prototypes 

String  []  proto_list  =  capsRef.get_proto_list(ownerWindow.getCapsUser()); 
byte[]  proto_file; 

String  selected  =  (String)  JOptionPane.showInputDiaIog  (ownerWindow, 

"Select  a  protoype  :  ",  "Open", 
JOptionPane.INFORMATION_MESSAGE,  null, 
proto_list,  proto_list  [0]); 


try 

{ 

//open  the  selected  file  from  the  remote  server 

proto_file  =  capsRef.open_proto  (selected,  ownerWindow.getCapsUserO); 
if  (proto_file  —  null) 
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{ 

JOptionPane.showMessageDialog  (ownerWindow, 

"The  selected  prototype  file  cannot  be  opened", 

"Error  Message",  JOptionPane.ERROR_MESSAGE); 

} 

else 

{ 

try  //convert  the  selected  file  from  a  byte  array  back  to  a  file 

{ 

String  protoHome  =  System.getProperty  ("PROTOTYPEHOME"); 

File  protoDir; 

if  (protoHome  =  null)  //  If  it  is  not  set  as  a  command  line  argument 

{ 

File  homeDir  =  FileSystemView.getFileSystemView  ().getHomeDirectory  Q; 
protoHome  =  new  String  (homeDir  +  File.separator  +  ".caps"); 
protoDir  =  new  File  (protoHome); 
if  (JprotoDir.exists  0) 

{ 

protoDir.mkdirs  0; 

} 

} 

else 

{ 

protoDir  =  new  File  (protoHome); 
if  (IprotoDir.exists  0) 

{ 

protoDir.mkdirs  0; 

} 

} 

File  selectedDir  =  new  File  (protoHome  +  File.separator  +  selected); 
if  (IselectedDir.exists  0) 

{ 

selectedDir.mkdirs  0; 

} 

else 

{ 

ownerWindow.setLabel  ("The  remote  file  will  overwrite  an  existing  local  one" 

} 

File  file  =  new  File  (selectedDir.getAbsolutePath  0  +  File.separator  + 
selectedDir.getParentFile  O.getName  0  +  ".psdl"); 
boolean  tempBoolean  =  fiIe.createNewFile(); 

FileOutputStream  fos  =  new  FileOutputStream  (file); 

fos.  write  (proto__file); 

fos.closeO; 

ownerWindow.setPrototype  (file); 

ownerWindow.setProtoName  (selectedDir.getParentFile  O.getName  0); 
ownerWindow.setProtoVersion  (selectedDir.getName  0); 

} 

catch  (Exception  e) 

{ 

JOptionPane.showMessageDialog  (ownerWindow, 

"The  selected  prototype  file  was  retrieved  but  cannot  be  opened", 

"Error  Message",  JOptionPane.ERROR_MESSAGE); 
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System.outprintln  (e); 

} 

} 

} 

catch  (DistributedCaps.DistCapsPackage.cantReadFile  e2) 

{ 

JOptionPane.showMessageDialog  (ownerWindow, 

’’The  selected  prototype  file  cannot  be  opened1’, 

’’Error  Message”,  JOptionPane.ERROR_MESSAGE); 
System.outprintln  (el); 

} 

} 

}//End  of  processOpenMenuItem 


/** 

*  Handles  the  event  which  is  caused  by  selecting  the  'Commit1  menu  item. 

*/ 

public  void  processCommitWorkMenuItem  0 

{ 

setCursor  (new  Cursor(Cursor.WAIT_CURSOR)); 

File  proto  =  ownerWindow.getPrototypeO; 

String  protoName  =  ownerWindow.getProtoNameO; 

if  (  protoName  =  null)  //  No  prototype  is  selected  to  open 

{ 

JOptionPane-showMessageDialog  (ownerWindow, 

”No  prototype  is  selected.”,  ’’Error  Message”,  JOptionPane.ERRORJVIESSAGE); 

} 

else 

{ 

if  (ownerWindow.isOpenPrototypeSaved  0) 

{ 

try  //convert  the  file  to  a  byte  array  for  transfer  to  the  server 

{ 

FilelnputStream  in  =  new  FilelnputStream  (proto); 
byte[]  fileBuf  =  new  byte[in.available()]; 
in.read  (fileBuf); 

DistCaps  capsRef  -  ownerWindow.getCapsRefO; 

String  returnMsg  =  capsRef.commit(fileBuf,  protoName, 
ownerWindow.getProtoVersionO,  ownerWindow.getCapsUserO); 

ownerWindow.setLabel  (returnMsg); 

System.outprintln  (returnMsg); 


} 

catch  (Exception  el) 

{ 

System.err.println  (’’Error:  ”  +  el); 
el.printStackTrace  (System.out); 


} 

} 

else 
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{ 

ownerWindow.setLabel  ("You  must  save  the  prototype  before  committing  it"); 

} 

setCursor  (new  Cursor(Cursor.DEFAULT_CURSOR)); 

}  //end  of  processCommitWorkMenuItem 

}  //  End  of  the  class  PrototypeMenu 
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Class 


Tree  Deprecated  Index  Help 

PREV  CLASS  NEXT  CLASS  FRAMES  NO  FRAMES 

SUMMARY:  INNER  |  FIELD  |  CONSTR  |  METHOD  DETAIL:  FIELD  |  CONSTR  |  METHOD 


caps.CAPSMain 

Class  CAPSMainWindow 

java . lang .Object 

I 

+ — java . awt . Component 

I 

+ — j  ava . awt . Container 

I 

+-- j  ava . awt .Window 

I 

+ — j  ava . awt . Frame 

I 

+ — javax . swing . JFrame 

I 

+ — caps  .  CAPSMain .  CAPSMainWindow 


public  class  CAPSMainWindow 
extends  javax. swing. JFrame 

The  main  CAPS  window. 

See  Also: 

Serialized  Form 


_ _ _ _ _ _ _ — - 1 

Inner  classes  inherited  from  class  javax.swing.JF rame _ 

javax . swing . JFrame . Accessible JFrame 


Inner  classes  inherited  from  class  java.awt.Component 

j  ava . awt . Component . AWTTreeLock 


142 


Field  Summary 

private 

DistributedCaps . DistCaps 

capsRef 

The  object  reference  to  the  CAPS  server. 

private 

static  java.lang. String 

capsUser 

The  private  attribute  for  holding  capsUser. 

private .  int 

HEIGHT 

The  height  of  the  frame. 

private 

static  java . util . Vector 

openPro to types 

The  Vector  that  holds  references  to  the  open  prototypes 

private 

static  java.lang. String 

protoName 

The  private  attribute  for  holding  protoName. 

private  java.io.File 

prototype 

The  File  that  contains  the  PSDL  prototype. 

private 

static  java.lang. String 

protoVersion 

The  private  attribute  for  holding  protoVersion. 

private  int 

WIDTH 

The  width  of  the  frame. 

Fields  inherited  from  class  javax.swing.JFrame 

accessibleContext,  defaultCloseOperation,  rootPane,  rootPaneCheckingEnabled 


Fields  inherited  from  class  java.awt.Frame 

base,  CROSSHAIR_CURSOR,  DEFAULTJZURSOR,  E_RESIZE_CURSOR,  f rameSerializedDataVersion, 
HAND_CURSOR,  icon,  ICONIFIED,  mbManagement,  menuBar,  MOVE_CURSOR,  N_RESIZE_CURSOR, 
nameCounter,  NE_RESIZE_CURSOR,  NORMAL,  NW_RESIZE_CURSOR,  ownedWindows ,  resizable, 
S_RESIZE_CURSOR,  SE_RESIZE_CURSOR,  serialVersionUID,  state,  SW_RESIZE_CURSOR, 

TEXT  CURSOR,  title,  W_RESIZE_CURSOR,  WAIT_CURSOR,  weakThis 


Fields  inherited  from  class  java.awt.Window 

active,  base,  focusMgr,  inputContext ,  nameCounter,  OPENED,  ownedWindowList , 
serialVersionUID,  state,  warningstring,  weakThis,  windowListener , 
windowSerializedDat aVers ion 

Fields  inherited  from  class  java.awtContainer 

component,  containerListener,  containerSerialized'DataVersion,  dispatcher,  layoutMgr, 
maxSize,  ncomponents,  serialVersionUID 
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Fields  inherited  from  class  java.awt.Component _ _ _ 

actionListenerK,  adjustmentListenerK,  appContext,  assert,  background, 

BOTTOM  ALIGNMENT,  CENTER_ALIGNMENT,  changeSupport ,  componentListener,  _ 
componentListenerK,  componentOrientation,  componentSerializedDataVersion, 
containerListenerK,  cursor,  dropTarget,  enabled,  eventMask,  focusListener, 
focusListenerK,  font,  foreground,  hasFocus,  height,  incRate,  mputMethodListener, 
inputMethodListenerK,  islnc,  isPacked,  itemListenerK,  keyListener,  keyListenerK, 
LEFT  ALIGNMENT,  locale,  LOCK,  minSize,  mouseListener ,  mouseListenerK,  ^ 
mouseMotionListener,  mouseMotionListenerK,  name,  nameExplicitlySet,  newEventsOnly, 
ownedWindowK,  parent,  peer,  peerFont,  popups,  prefSize,  RIGHT_ALIGNMENT , 
serialVersionUID,  textListenerK,  TOP_ALIGNMENT ,  valid,  visible,  width, 
windowListenerK,  x,  y  _ _ _ _ _ 


Constructor  Summary _ 

CAPSMainWindow ( DistributedCaps . DistCaps  objRef ) 

The  constructor  for  this  class. 


Method  Summary 

void 

editPrototype ( ) 

Opens  the  graphics  editor  to  edit  a  prototype. 

DistributedCaps . DistCaps 

getCapsRef ( ) 

Retrieves  the  curent  reference  to  the  caps  server. 

java. lang. String 

getCapsUser ( ) 

Gets  the  capsUser 

java. util .Vector 

getOpenPrototypes ( ) 

Returns  the  vector  that  holds  the  open  prototype  files. 

java. lang. St ring 

getProtoName ( ) 

Gets  the  prototype  name 

j  ava . io . File 

getPrototype ( ) 

Retrieves  the  curent  prototype  file. 

java. lang. String 

getProtoVersion ( ) 

Gets  the  prototype  version 

void 

initialize ( ) 

Initializes  the  CAPS  main  window. 

boolean 

isOpenPrototypeSaved( ) 

Checks  if  the  status  of  any  of  the  open  prototypes  is  'saveRequired . 

boolean 

i s Pro to tvpeChanged ( ) 

Checks  whether  or  not  the  current  prototype  file  is  already  used  by  a 

PSDL  Editor. 

static  void 

removeE di to r ( caps . GraphEditor . Edi tor  6 ) 

Removes  one  element  from  the  openPrototypes  vector. 

void 

setLabel( java. lang. String  msg) 

Sets  the  label  to  the  string  message  passed  in. 

void 

setProtoName ( j ava . lang. String  name) 
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bets  the  prototype  name  to  the  argument 


void 

setPrototype (java . io. File  f) 

Sets  the  prototype  file  to  the  argument. 

void 

setProtoVersion (i ava . lanq . Strinq  version) 

Sets  the  prototype  version  to  the  argument 

Methods  inherited  from  class  javax.swing.JFrame 

addlmpl,  createRootPane,  createRootPaneException,  frame Ini t,  getAccessibleContext , 
get Content Pane,  getDef aultCloseOperation,  getGlassPane,  getJMenuBar,  getLayeredPane, 
getRootPane,  isRootPaneCheckingEnabled,  paramString,  processKeyEvent , 
processWindowEvent,  remove,  setContentPane,  set Def aultCloseOperation,  setGlassPane, 
set JMenuBar,  setLayeredPane,  setLayout,  setRootPane,  setRootPaneCheckingEnabled, 
update 


Methods  inherited  from  class  java.awt Frame 

,  addNotify,  addToFrameList ,  constructComponentName,  finalize,  getCursorType, 
getFrames,  getlconlmage,  getMenuBar,  getState,  getTitle,  initIDs,  isResizable, 
post ProcessKeyE vent ,  readOb j ect ,  remove ,  remove FromFrameLis t ,  removeNot if y , 
setCursor,  setlconlmage,  setMenuBar,  setResizable,  setState,  setTitle,  writeObject 


Methods  inherited  from  class  java.awt. Window 

addOwnedWindow,  addWindowListener,  applyResourceBundle,  applyResourceBundle, 
connect OwnedWindow,  dispatchEventlmpl ,  dispose,  eventEnabled,  getFocusOwner, 
getlnputContext,  -getLocale,  getOwnedWindows,  getOwner,  getToolkit,  getWarningString, 
hide,  isActive,  isShowing,  nextFocus,  ownedlnit,  pack,  postEvent,  postWindowEvent , 
preProcessKeyEvent ,  proces s Event ,  removeOwnedWindow,  removeWindowListener, 
setCursor,  setFocusOwner ,  setWarningString,  show,  toBack,  toFront,  transferFocus 


Methods  inherited  from  class  java.awt.Container 

add,  add,  add,  add,  add,  addContainerListener,  applyOrientation,  countComponents, 
deliverEvent,  dispatchEventToSelf ,  doLayout,  f indComponentAt ,  f indComponentAt , 
getAlignmentX,  getAlignmentY,  getComponent ,  getComponentAt ,  getComponentAt , 
getComponentCount,  getComponents_NoClientCode,  getComponent s ,  getCursorTarget , 
get Insets,  get Layout ,  getMaximumSize,  getMinimumSize,  ge tMouseEvent Target , 
getPref erredSize,  getWindow,  insets,  invalidate,  invalidateTree,  isAncestorOf , 
layout,  lightweightPrint ,  list,  list,  locate,  minimumSize,  paint,  paintComponents , 
postsOldMouseEvents,  pref erredSize,  print,  print Components ,  print OneComponent , 
proces sCont ainer Event ,  proxyEnableEvent s ,  proxyRequest Focus ,  remove ,  removeAll , 
removeContainerListener,  set Font ,  updateCursor,  validate,  validateTree 
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Methods  inherited  from  class  java.awt.Component _ _ _ _ _ 

action,  add,  addComponentListener ,  addFocusListener ,  addlnputMethodListener, 
addKeyListener ,  addMouseListener ,  addMouseMotionListener ,  addPropertyChangeListener, 
addPropertyChangeListener,  arelnputMethodsEnabled,  bounds,  checklmage,  checklmage, 
coalesceEvents,  contains,  contains,  createlmage,  createlmage,  disable, 
disableEvents,  dispatchEvent,  enable,  enable,  enableEvents,  enablelnputMethods, 
firePropertyChange,  getBackground,  getBounds,  getBounds,  getColorModel, 
getComponentOrientation,  getCursor,  getDropTarget,  getFont_NoClientCode,  getFont, 
getFontMetrics,  getForeground,  getGraphics,  getHeight,  getlnputMethodRequests, 
getlntrinsicCursor,  getLocation,  getLocation,  getLocationOnScreen,  getName, 
getNativeContainer,  getParent_NoClientCode,  getParent,  getPeer,  getSize,  getSize, 
getToolkitlmpl,  getTreeLock,  getWidth,  getWindowForObject,  getX,  getY,  gotFocus, 
handleEvent,  hasFocus,  imageUpdate,  inside,  isDisplayable,  isDoubleBuf fered, 
isEnabled,  isEnabledlmpl,  isFocusTraversable,  isLightweight,  isOpaque,  isValid, 
isVisible,  keyDown,  keyUp,  list,  list,  list,  location,  lostFocus,  mouseDown, 
mouseDrag,  mouseEnter,  mouseExit,  mouseMove,  mouseUp,  move,  nextFocus,  paintAll, 
preparelmage,  preparelmage,  printAll,  processComponentEvent,  processFocusEvent, 
processInputMethodEvent,  processMouseEvent,  processMouseMotionEvent, 
removeComponentListener,  removeFocusListener,  removelnputMethodListener, 
removeKeyListener,  removeMouseListener,  removeMouseMotionListener, 
removePropertyChangeListener,  removePropertyChangeListener,  repaint,  repaint, 
repaint,  repaint,  requestFocus,  reshape,  resize,  resize,  setBackground,  setBounds, 
setBounds,  setComponentOrientation,  setDropTarget,  setEnabled,  setForeground, 
setLocale,  setLocation,  setLocation,  setName,  setSize,  setSize,  setVisible,  show, 
size,  toString,  transferFocus  _ 


Methods  inherited  from  class  java.lang.Object _ _ 

clone,  equals,  getClass,  hashCode,  notify,  notifyAll,  registerNatives ,  wait,  wait, 
wait 


Field  DetaU 


WIDTH 

private  final  int  WIDTH 

The  width  of  the  frame. 


HEIGHT 

private  final  int  HEIGHT 

The  height  of  the  frame. 


prototype 

private  java. io. File  prototype 

The  File  that  contains  the  PSDL  prototype. 
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capsRef 

private  DistributedCaps . DistCaps  capsRef 
The  object  reference  to  the  CAPS  server. 


protoName 

private  static  java . lang. String  protoName 
The  private  attribute  for  holding  protoName. 


protoVersion 

private  static  java . lang . String  protoVersion 
The  private  attribute  for  holding  protoVersion. 


capsUser 

private  static  java. lang. String  capsUser 
The  private  attribute  for  holding  capsUser. 


openPrototypes 

private  static  java. util .Vector  openPrototypes 

The  Vector  that  holds  references  to  the  open  prototypes 

Constructor  Detail 

CAPSMain  Window 

public  CAPSMainWindow ( DistributedCaps. DistCaps  objRef) 

The  constructor  for  this  class. 

Parameters: 

ob j  Ref  -  The  reference  to  the  CAPS  object  on  the  server 
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Method  Detail 


initialize 

public  void  initialized 

Initializes  the  CAPS  main  window. 


setPrototype 

public  void  setPrototype ( java . io . File  f) 

Sets  the  prototype  file  to  the  argument. 

Parameters: 

f  -  The  File  that  contains  the  PSDL  prototype. 


setLabel 

public  void  setLabel (java . lang. String  msg) 

Sets  the  label  to  the  string  message  passed  in. 

Parameters: 

msg  -  The  message  to  be  displayed. 


getPrototype 

public  java. io. File  getPrototype ( ) 

Retrieves  the  curent  prototype  file. 

Returns: 

the  File  that  contains  the  PSDL  prototype. 


getCapsRef 

public  DistributedCaps . DistCaps  getCapsRef ( ) 

Retrieves  the  curent  reference  to  the  caps  server. 

Returns: 

the  reference  to  the  caps  server  object. 


getOpenPrototypes 
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public  java. util .Vector  getOpenPrototypes { ) 

Returns  the  vector  that  holds  the  open  prototype  files. 

Returns: 

the  vector  that  contains  the  open  prototype  files. 


setProtoName 

public  void  setProtoName ( j ava . lang. String  name) 

Sets  the  prototype  name  to  the  argument 

Parameters: 

name  -  The  string  that  contains  the  prototype's  name 


setProtoVersion 

public  void  setProtoVersion (java. lang. String  version) 

Sets  the  prototype  version  to  the  argument 

Parameters: 

version  -  The  string  that  contains  the  prototype's  version 


getProtoName 

public  j ava . lang . String  getProtoName ( ) 
Gets  the  prototype  name 


getProtoVersion 

public  j ava . lang. String  getProtoVersion ( ) 

Gets  the  prototype  version 


getCapsUser 

public  j ava . lang . String  getCapsUser ( ) 

Gets  the  capsUser 
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editPrototype 

public  void  editPrototype ( ) 

Opens  the  graphics  editor  to  edit  a  prototype. 


isPrototypeChanged 

public  boolean  isPrototypeChanged ( ) 

Checks  whether  or  not  the  current  prototype  file  is  already  used  by  a  PSDL  Editor. 

Returns: 

true  if  selected  prototype  is  not  already  open 


removeEditor 

public  static  void  removeEditor (caps . GraphEditor . Editor  e) 

Removes  one  element  from  the  openPrototypes  vector. 

Parameters: 

e  -  the  editor  that  is  going  to  be  removed  from  the  vector. 


isOpenPrototypeSaved 

public  boolean  isOpenPrototypeSaved ( ) 

Checks  if  the  status  of  any  of  the  open  prototypes  is  'saveRequired'.  Prompts  the  user  to  save  the 
prototype. 

Returns: 

true  if  none  of  the  prototypes  need  saving. 


Class 


Tree  Deprecated  Index  Help 


PREV  CLASS  NEXT  CLASS 
SUMMARY:  INNER  |  FIELD  |  CONSTR  |  METHOD 


FRAMES  NO  FRAMES 

DETAIL:  FIELD  |  CONSTR  |  METHOD 
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Class 


Tree  Deprecated  Index  Help 

PREV  CLASS  NEXT  CLASS  FRAMES  NO  FRAMES 

SUMMARY:  INNER  |  FIELD  |  CONSTR  |  METHOD  DETAIL:  FIELD  |  CONSTR  |  METHOD 


caps.CAPSMain 

Class  ExecSupportMenu 

j  ava . lang . Ob j  ect 

I 

+ — java . awt . Component 

I 

+ — j  ava . awt . Container 

I 

+ — j  avax . swing . JComponent 

I 

+ — javax. swing. AbstractButton 

I 

+ — j  avax . swing . JMenuItem 

I 

+ — j  avax . swing . JMenu 

I 

+--caps . CAPSMain . ExecSupportMenu 


public  class  ExecSupportMenu 
extends  javax.swing.  JMenu 
implements  java.awt.event.ActionListener 

This  class  holds  the  'Exec  Support'  menu  items. 

See  Also: 

Serialized  Form 


Inner  classes  inherited  from  class  javax.swing.  JMenu 

j  avax .  swing .  JMenu .  Accessible  JMenu,  j  avax .  swing .  JMenu .  MenuChangeLis  tener , 
j  avax . swing . JMenu . WinLis tener 


Inner  classes  inherited  from  class  javax.swing.  JMenuItem 

javax.  swing.  JMenuItem.  Accessible  JMenu  I  tern 


Inner  classes  inherited  from  class  javax.swing.AbstractButton 

j  avax . swing . AbstractButton . Access ibleAbs tractButton, 
j  avax . swing . AbstractButton . ButtonChangeLis tener 
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Inner  classes  inherited  from  class  javax.swing.JComponent _ 

javax.  swing.  JComponent  .  Access ible JComponent,  javax.  swing .  JComponent.  IntVector, 
javax . swing . JComponent . KeyboardBinding,  javax . swing . JComponent . Keyboards tate 


Inner  classes  inherited  from  class  java.awt.Component 

j  ava . awt . Component . AWTTreeLock 


Field  Summary 

private  javax.swing.JMenuItem 

compi 1 eMenu I tern 

Initiates  the  'Compile'  event 

private  javax.swing.JMenuItem 

executeMenuItem 

Initiates  the  'Execute'  event 

protected 

caps . CAPSMain . CAPSMainWindow 

ownerWindow 

The  main  window  which  owns  this  menu. 

private  javax.swing.JMenuItem 

s cheduleMenuI tem 

Initiates  the  'Schedule'  event 

private  javax.swing.JMenuItem 

translateMenuItem 

Initiates  the  'Translate'  event 

Fields  inherited  from  class  j  avax.swin g.  JMenu _ 

delay,  listenerRegistry,  menuChangeListener ,  menuEvent,  popupListener,  popupMenu, 
uiClassID  _ . 


Fields  inherited  from  class  javax.swing.JMenuItem 

accelerator ,  uiClassID 


Fields  inherited  from  class  javax.swing.AbstractButton _ 

actionListener,  BORDER_PAINTED_CHANGED_PROPERTY,  changeEvent,  changeListener, 
CONTENT_AREA_FILLED_CHANGED_PROPERTY,  contentAreaFilled,  defaultlcon,  defaultMargin, 
DISABLED  ICON_CHANGED_PROPERTY,  DISABLED_SELECTED_ICON_CHANGED_PROPERTY, 
disabledlcon,  disabledSelectedlcon,  FOCLJS_PAINTED_CHANGED_PROPERTY, 

HORIZONTAL  ALIGNMENT_CHANGED_PROPERTY,  HORIZONTAL_TEXT_POSITION_CHANGED_PROPERTY, 
horizontalAlignment,  horizontalTextPosition,  ICON_CHANGED_PROPERTY,  itemListener, 
margin,  MARGIN  CHANGED_PROPERT Y ,  MNEMONIC_CHANGED_PROPERTY ,  model, 

MODEL  CHANGED  PROPERTY,  paintBorder,  paintFocus,  PRESSED_ICON_CHANGED_PROPERTY , 
pressedlcon,  ROLLOVER_ENABLED_CHANGED_PROPERTY,  ROLLOVER_ICON_CHANGED_PROPERTY , 
ROLLOVER_SELECTED_ICON_CHANGED_PROPERTY,  rolloverEnabled,  rolloverlcon, 
rolloverSelectedlcon,  SELECTED_ICON_CHANGED_PROPERTY,  selectedlcon,  text, 
TEXT_CHANGED_PROPERTY,  VERTICAL_ALIGNMENT_CHANGED_PROPERTY , 

VERTICAL  TEXT  POSITION  CHANGED  PROPERTY,  verticalAlignment,  verticalTextPosition 
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Fields  inherited  from  class  javax.swing.JComponent 

_bounds ,  accessibleContext ,  alignmentX,  alignmentY,  ANCESTOR_USING_BUFFER, 
ancestorNotifier,  autoscroller,  border,  changeSupport,  clientProperties,  flags, 
HAS_FOCUS,  IS_DOUBLE_BUFFERED,  IS_OPAQUE,  IS__PAINTING_TILE,  KEYBOARDJ3INDINGSJCEY, 
listenerList ,  maximumSize,  minimumSize,  NEXT_FOCUS,  paint ImmediatelyClip, 
paint ingChild,  preferredSize,  readObj ect Callbacks ,  REQUEST_FOCUS_DISABLED,  tmpRect, 
TOOL_T  I  P__TEXT_KE  Y ,  ui,  uiClassID,  UNDEFINED__CONDITION,  vetoable'ChangeSupport , 

WHEN  ANCESTOR  OF  FOCUSED  COMPONENT,  WHEN  FOCUSED,  WHEN  IN  FOCUSED  WINDOW 


Fields  inherited  from  class  java.awt.Container 

component,  containerListener,  containerSerializedDat aversion,  dispatcher,  layoutMgr, 
maxSize,  ncomponents,  serialVersionUID 


Fields  inherited  from  class  java.awt.Component 

actionListenerK,  adjustmentListenerK,  appContext,  assert,  background, 
BOTTOM_ALIGNMENT ,  CENTER_ALIGNMENT ,  changeSupport ,  component Lis tener , 
componentListenerK,  componentOrientation,  component SerializedDat a Vers ion, 
containerListenerK,  cursor,  dropTarget,  enabled,  eventMask,  focusListener, 
focusListenerK,  font,  foreground,  hasFocus,  height,  incRate,  inputMethodListener, 
inputMethodListenerK,  islnc,  isPacked,  itemListenerK,  keyListener,  keyListenerK, 
LEFT_ALIGNMENT,  locale,  LOCK,  minSize,  mouseListener ,  mouseListenerK, 
mouseMotionListener ,  mouseMotionListenerK,  name,  nameExplicitlySet ,  newEventsOnly, 
ownedWindowK,  parent,  peer,  peerFont,  popups,  prefSize,  RIGHT_ALIGNMENT , 
serialVersionUID,  textListenerK,  TOP_ALIGNMENT ,  valid,  visible,  width, 
windowListenerK,  x,  y 


Constructor  Summary 

ExecSupportMenu ( caps . CAPSMain . CAPSMainWindow  owner) 

Constructor  for  this  class. 


1 

Method  Summary 

void 

actionPerf ormed ( j  ava . awt . event . Act ionEvent  e ) 

Action  event  handler  for  the  menu  events. 

Methods  inherited  from  class  javax.swing.JMenu 

,  add,  add,  add,  add,  addMenuListener,  addSeparator,'  buildMenuElementArray, 
clearListenerRegistry,  createActionChangeListener ,  createMenuChangeListener, 
createWinLis tener,  doClick,  ensurePopupMenuCreated,  f ireMenuCanceled, 
fireMenuDeselected,  fireMenuS elected,  getAccessibleContext ,  ge t Component ,  get Delay, 
get Item,  getltemCount,  getMenuComponent ,  getMenuComponentCount ,  getMenuComponents, 
getPopupMenu,  getPopupMenuOrigin,  getSubElements,  getUIClassID,  insert,  insert, 
insert,  insert Separator,  isMenuComponent ,  isPopupMenuVisible,  isS elected,  isTearOf f , 
isTopLevelMenu,  menuSelectionChanged,  par amSt ring,  processKeyEvent , 
registerMenuItemForAction,  remove,  remove,  remove,  removeAll,  removeMenuListener , 
setAccelerator,  set Delay,  setMenuLocation,  setModel,  setPopupMenuVisible, 
set Selected,  translateToPopupMenu,  translateToPopupMenu, 
unregis terMenuItemForAction,  updateUI ,  writeObj ect 
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Methods  inherited  from  class  javax.swing.JMenuItem 

addMenuDragMouseListener ,  addMenuKeyListener ,  alwaysOnTop,  f ireMenuDragMouseDragged, 
f ireMenuDragMouseEntered,  f ireMenuDragMouseExited,  f ireMenuDragMouseRe leased, 
f ireMenuKeyPressed,  f ireMenuKeyReleased,  f ireMenuKeyTyped,  get Accelerator,  init , 
isArmed,  processKeyEvent ,  processMenuDragMouseEvent ,  processMenuKeyEvent , 
processMouseEvent ,  readObject ,  removeMenuDragMouseListener ,  removeMenuKeyListener, 
setArmed,  setEnabled,  'setUI 


Methods  inherited  from  class  javax.swing.AbstractButton 

addActionListener,  addChangeListener,  addltemListener ,  checkHorizontalKey, 
checkVerticalKey,  createActionListener,  createChangeListener ,  createltemListener , 
doClick,  f ireActionPer formed,  f ire ItemS tat eChanged,  fireStateChanged, 
getActionCommand,  getDisabledlcon,  getDisabledSelectedlcon,  getHorizontalAlignment , 
getHorizontalTextPosition,  getlcon,  getLabel,  getMargin,  getMnemonic,  getModel, 
get Pres sedl con,  get Rollover I con,  getRolloverSelectedlcon,  ge t Select edl con, 
gets elect edObj ects,  getText ,  getUI,  getVerticalAlignment ,  getVerticalText Posit ion, 
is Border Painted,  isContentAreaFilled,  is Focus Painted,  isRolloverEnabled, 
paint Border,  removeActionListener,  removeChangeListener,  removeltemListener, 
setActionCommand,  set Border Painted,  setContentAreaFilled,  setDisabledlcon, 
setDisabledSelectedlcon,  set Focus Painted,  setHorizontalAlignment , 

setHorizontalTextPosition,  setlcon,  setLabel,  setMargin,  setMnemonic,  setMnemonic, 
setPressedlcon,  setRolloverEnabled,  set Rollover I con,  setRolloverSelectedlcon, 
set Select edl con,  set Text ,  setUI,  setVerticalAlignment ,  set Vert icalText Posit ion 


Methods  inherited  from  class  javax.swing.JComponent 

_paintlmmediately,  addAncestorListener,  addNotify,  addPropertyChangeListener , 

; addPropertyChangeListener,  addVetoableChangeListener ,  adj ust PaintFlags , 
bindingForKeyStroke,  checklfChildObscuredBySibling,  computeVisibleRect , 
computeVisibleRect ,  contains,  cr eat -ToolTip,  enableSerialization, 
firePropertyChange,  f irePropertyChange,  f irePropertyChange,  firePropertyChange, 
firePropertyChange,  firePropertyChange,  firePropertyChange,  firePropertyChange, 
firePropertyChange,  f ireVetoableChange,  getActionForKeyStroke,  getAlignmentX, 
getAlignmentY,  getAutoscrolls ,  get Border ,  get Bounds,  get Client Proper ties, 
getClient Property,  get Component Graphics,  getConditionForKeyStroke, 
getDebugGraphicsOptions,  getFlag,  getGraphics,  getHeight,  getlnset s,  getlnsets, 
getLocation,  getMaximumSize,  getMinimumSize,  getNextFocusableComponent , 
getPreferredSize,  get Regis teredKeyStrokes,  get Root Pane,  getSize,  getToolTipLocation, 
getToolTipText ,  getToolTipText ,  getTopLevelAncestor,  getVisibleRect ,  getWidth,  getX, 
getY,  grabFocus,  hasFocus,  isDoubleBuf fered,  isFocusCycleRoot ,  isFocusTraversable, 
isLight weight Component ,  isManagingFocus,  isOpaque,  isOptimizedDrawingEnabled, 
is Paint ingTile,  isRequestFocusEnabled,  isValidateRoot ,  keyboardBindings,  paint, 
paintChildren,  paint Component ,  paint Immediately,  paint Immediately,  paintWithBuf fer, 
processComponentKeyEvent ,  proces s Focus Event ,  processKeyBinding,  processKeyBindings, 
processKeyBindingsForAUComponents,  processMouseMotionEvent ,  put Client Property, 
r ect angle I sObs cured,  rectangle I sObs cur edBvS idling,  registerKeyboardAction, 
registerKeyboardAction,  registerWithKeyboardManager,  removeAncestorListener, 
removeNotify,  remove Proper tyChangeListener,  removePropertyChangeListener , 
removeVetoableChangeListener,  repaint,  repaint,  requestDefaultFocus ,  requestFocus, 
resetKeyboardActions ,  reshape,  revalidate,  scrollRectToVisible,  setAlignmentX, 
setAlignmentY,  setAutoscrolls,  setBackground,  setBorder,  setDebugGraphicsOptions, 
setDoubleBuf fered,  setFlag,  setFont,  setForeground,  setMaximumSize,  setMinimumSize, 
setNext Focus ableComponent,  setOpaque,  setPaintingChild,  set Preferreds ize, 
setRequestFocusEnabled,  setToolTipText ,  setUI,  setVisible,  shouldDebugGraphics, 
super ProcessMouseMotionEvent,  unregisterKeyboardAction, 
unregisterWithKeyboardManager,  update 
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Methods  inherited  from  class  java.awt.Container 

add,  add,  add,  add,  addContainerListener ,  addlmpl,  applyOrientation, 
countComponents,  deliverEvent ,  dispatchEventlmpl,  dispatchEventToSelf ,  doLayout , 
eventEnabled,  f indComponentAt ,  f indComponentAt ,  getComponent ,  getComponentAt , 
getComponentAt ,  getComponentCount ,  getComponents_NoClientCode,  getComponent s , 
getCursorTarget ,  getLayout,  getMouseEventTarget ,  getWindow,  initIDs,  insets, 
invalidate,  invalidateTree,  isAncestorOf ,  layout,  lightweightPrint ,  list,  list, 
locate,  minimumSize,  nextFocus,  paintComponents,  postProcessKeyEvent , 
post sOldMouseE vents ,  preferredSize,  preProcessKeyEvent ,  print,  print Components, 
printOneComponent ,  processContainerEvent ,  processEvent ,  proxyEnableEvents, 
proxyRequest Focus,  removeContainerListener ,  setCursor,  setFocusOwner ,  setLayout, 
transf erFocus ,  updateCursor,  validate,  validateTree 


Methods  inherited  from  class  java.awt.Component 

action,  add,  addComponent Listener,  addFocusListener ,  addlnputMethodListener , 
addKeyListener,  addMouseListener,  addMouseMotionListener ,  arelnputMethodsEnabled, 
bounds,  checklmage,  checklmage,  coalesceEvents,  constructComponentName,  contains, 
createlmage,  createlmage,  disable,  disableEvents,  dispatchEvent,  enable,  enable, 
enableEvent s ,  enable InputMethods ,  get Background,  get Bounds ,  getColorModel , 
getComponentOrientation,  getCursor,  getDropTarget ,  getFont_NoClientCode,  get Font , 
getFontMetrics ,  get Foreground,  get InputContext ,  get InputMethodRequests , 
getlntrinsicCursor,  get Locale,  get Location,  getLocationOnScreen,  getName, 
getNativeContainer,  get Parent_NoClientCode,  get Parent,  get Peer,  getSize,  get Tool kit , 
getToolkitlmpl,  getTreeLock,  getWindowForObj ect ,  gotFocus,  handleEvent,  hide, 
imageUpdate,  inside,  isDisplayable,  isEnabled,  isEnabledlmpl,  isLightweight , 
isShowing,  isValid,  isVisible,  keyDown,  keyUp,  list,  list,  list,  location, 
lostFocus,  mouseDown,  mouseDrag,  mouseEnter,  mouseExit',  mouseMove,  mouseUp,  move, 
nextFocus,  paintAll,  postEvent,  preparelmage,  preparelmage,  printAll, 
processComponent Event,  process InputMethodEvent ,  processMouseEvent ,  remove, 
removeComponent Listener,  removeFocusListener ,  remove InputMethodListener, 
removeKeyListener,  removeMouseListener,  removeMouseMotionListener,  repaint,  repaint, 
repaint,  resize,  resize,  setBounds,  setBounds,  setComponentOrientation, 
setDropTarget ,  setLocale,  setLocation,  setLocation,  setName,  setSize,  setSize,  show, 
show,  size,  toString,  transferFocus 


Methods  inherited  from  class  java.lang.Object _ 

clone,  equals,  finalize,  getClass,  hashCode,  notify,  notifyAll,  registerNatives, 
wait,  wait,  wait 


|  Field  Detail _ _ 

translateMenuItem 

private  javax. swing . JMenuItem  translateMenuItem 

Initiates  the  'Translate'  event 


scheduleMenuItem 

private  javax. swing. JMenuItem  scheduleMenuItem 
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Initiates  the  'Schedule'  event 


com  pileMen  ultem 

private  j avax . swing . JMenuItem  compileMenuItem 
Initiates  the  'Compile'  event 


executeMenuItem 

private  j avax . swing . JMenuItem  executeMenuItem 

Initiates  the  'Execute'  event 


ownerWindow 

protected  caps. CAPSMain. CAPSMainWindow  ownerWindow 

The  main  window  which  owns  this  menu. 


Constructor  Detail 


ExecSupportMenu 

public  ExecSupportMenu ( caps . CAPSMain . CAPSMainWindow  owner) 

Constructor  for  this  class. 

Parameters: 

owner  -  CAPSMainWindow  that  owns  the  menu 

Method  Detail 


actionPerformed 

public  void  actionPerformed ( java . awt . event .Act ionEvent  e) 

Action  event  handler  for  the  menu  events. 

Specified  by: 

actionPerformed  in  interface  java.awt.event.ActionListener 

Parameters: 

e  -  The  action  event  that  is  created  by  selecting  a  menu  item 
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Tree  Deprecated  Index  Help 

PREV  CLASS  NEXT  CLASS  FRAMES  NO  FRAMES 

SUMMARY:  INNER  |  FIELD  |  CONSTR  |  METHOD  DETAIL:  FIELD  |  CONSTR  |  METHOD 


caps.CAPSMain 

Class  PrototypeMenu 

java.lang. Object 

I 

+ — j  ava . awt . Component 

I 

+ — j  ava . awt . Container 

I 

+ — javax. swing. JComponent 

I 

+ — javax. swing. AbstractButton 

i 

+ — javax. swing. JMenuItem 

+ — j  avax . swing . JMenu 

I 

+  —  caps  .  CAPSMain .  PrototypeMenu 

public  class  PrototypeMenu 

extends  javax.swing.  JMenu 

implements  java.awt.event.ActionListener 

This  class  holds  the  'Prototype'  menu  items. 

See  Also: 

Serialized  Form 


Inner  classes  inherited  from  class  javax.swing.  JMenu 

j  avax .  swing .  JMenu .  Accessible  JMenu,  j  avax .  swing .  JMenu .  MenuChangeLis  tener , 
j  avax . swing .  JMenu . WinLis tener 


Inner  classes  inherited  from  class  javax.swing.  JMenuItem 

javax.  swing.  JMenuItem.  Accessible  JMenuItem 


Inner  classes  inherited  from  class  javax.swing.  AbstractButton 

j  avax . swing . AbstractButton . Acces  sibleAbs  tractBu tton , 
javax . swing . AbstractButton . ButtonChangeLis tener 
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Inner  classes  inherited  from  class  javax.swing.JComponent 

javax.  swing.  JComponent .  Accessible JComponent,  javax.  swing.  JComponent.  IntVector, 
javax. swing. JComponent . KeyboardBinding,  javax. swing. JComponent . Keyboards tate 


Inner  classes  inherited  from  class  java.awt.Component 

j  ava . awt . Component . AWTTreeLock 


Field  Summary 

private  javax.swing.JMenuItem 

commi tWorkMenuI tern 

Initiates  the  ’Commit  Work'  event 

private  javax.swing.JMenuItem 

newMenuItem 

Initiates  the  'New'  event 

private  javax.swing.JMenuItem 

openMenuI tem 

Initiates  the  'Open'  event 

protected 

caps . CAPSMain.CAPSMainWindow 

ownerWindow 

The  main  window  which  owns  this  menu. 

private  javax.swing.JMenuItem 

qui tMenuI tem 

Initiates  the  'Quit'  event 

private  javax.swing.JMenuItem 

retr ieveMenuI tem 

Initiates  the  'Retrieve  From  DDB'  event 

Fields  inherited  from  class  javax.swing.JMenu 

delay,  listenerRegistry,  menuChangeListener,  menuEvent,  popupListener,  popupMenu, 
uiClassID 


Fields  inherited  from  class  javax.swing.JMenuItem 

accelerator,  uiClassID 


Fields  inherited  from  class  javax.swing.AbstractButton 

actionListener,  BORDER_PAINTED_CHANGED_PROPERTY,  changeEvent,  changeListener , 
CONTENT_AREA_FILLED_CHANGED_PROPERTY,  contentAreaFilled,  defaultlcon,  def aultMargin, 
DISABLED_ICON_CHANGED_PROPERTY,  DISABLED_SELECTED_ICON_CHANGED_PROPERTY, 
disabled!! con,  disabledS elected!! con,  FOCUS_PAINTED_CHANGED_PROPERTY, 
HORIZONTAL_ALIGNMENT_CHANGED_PROPERTY,  HORIZONTAL_TEXT_POSITION_CHANGED_PROPERTY, 
horizontalAlignment ,  horizontalTextPosition,  ICON_CHANGED_PROPERTY,  itemListener, 
margin,  MARGIN_CHANGED_PROPERTY,  MNEMONIC_CHANGED_PROPERTY ,  model, 
MODEL_CHANGED_PROPERTY,  paintBorder,  paintFocus,  PRESSED_ICON_CHANGED_PROPERTY , 
pressedlcon,  ROLLOVER_ENABLED_CHANGED_PROPERTY,  ROLLOVER_ICON_CHANGED_PROPERTY, 
ROLLOVER_SELECTED_ICON_CHANGED_PROPERTY,  rolloverEnabled,  rollover I con, 
rolloverSelectedlcon,  SELECTED_ICON_CHANGED_PROPERTY,  selectedlcon,  text, 
TEXT_CHANGED_PROPERTY,  VERTICAL_ALIGNMENT_CHANGED_PROPERTY, 

VERTICAL  TEXT  POSITION  CHANGED  PROPERTY,  verticalAJLignment ,  verticalTextPosition 
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Fields  inherited  from  class  javax.swing.JComponent 

_bounds ,  accessibleContext,  alignmentX,  alignmentY,  ANCESTOR_CJSING_BUFFER, 
ancestorNotifier,  autoscroller,  border,  changeSupport,  clientProperties,  flags, 
HAS_FOCUS,  IS_DOUBLE_BUFFERED,  IS_OPAQUE,  IS_PAINTING_TIL£,  KEYBOARD_BINDINGS_KEY, 
listenerList,  maximumSize,  minimumSize,  NEXT_FOCUS,  paintlmmediatelyClip, 
paintingChild,  preferredSize,  readObjectCallbacks,  REQUEST_FOCUS_DISABLED,  tmpRect, 
TOOL_TIP_TEXT_KEY,  ui,  uiClassID,  UNDEFINED_CONDITION,  vetoableChangeSupport , 
WHEN_ANCESTOR_OF_FOCUSED_COMPONENT,  WHEN_FOCUSED,  WHEN  IN  FOCUSED  WINDOW 


Fields  inherited  from  class  java.awt.Container 

component,  containerListener,  containerSerializedDataVersion,  dispatcher,  layoutMgr, 
maxSize,  ncomponents,  serialVersionUID 


Fields  inherited  from  class  java.awtComponent 

actionListenerK,  adj ustmentListenerK,  appContext,  assert,  background, 
BOTTOM_ALIGNMENT,  CENTER_ALIGNMENT,  changeSupport,  componentListener, 
componentListenerK,  componentOrientation,  component SerializedDat aVers ion, 
containerListenerK,  cursor,  dropTarget,  enabled,  eventMask,  focusListener, 
focusListenerK,  font,  foreground,  hasFocus,  height,  incRate,  inputMethodListener, 
inputMethodListenerK,  islnc,  isPacked,  itemListenerK,  keyListener,  keyListenerK, 
LEFT_ALIGNMENT,  locale,  LOCK,  minSize,  mouseListener,  mouseListenerK, 
mouseMotionListener,  mouseMotionListenerK,  name,  nameExplicitlySet,  newEventsOnly, 
ownedWindowK,  parent,  peer,  peerFont,  popups,  prefSize,  RIGHT_ALIGNMENT, 
serialVersionUID,  textListenerK,  TOP_ALIGNMENT,  valid,  visible,  width, 
windowListenerK,  x,  y 


Constructor  Summary 

PrototypeMenu  ( caps  .  CAPSMain .  CAPSMainWindow  owner ) 

Constructor  for  this  class. 


Method  Summary 

void 

actionPerf ormed ( j  a va . awt . event . ActionEvent  e ) 

Action  event  handler  for  the  menu  events. 

void 

processCommitWorkMenuItem ( ) 

Handles  the  event  which  is  caused  by  selecting  the  'Commit'  menu  item. 

void 

proces sNewMenuI tem  ( ) 

Handles  the  event  which  is  caused  by  selecting  the  'New'  menu  item. 

void 

pro cessOpenMenuI tern ( ) 

Handles  the  event  which  is  caused  by  selecting  the  'Open'  menu  item. 
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Methods  inherited  from  class  javax.swing.JMenu  _ 

add,  add,  add,  add,  addMenuListener,  addSeparator,  buildMenuElementArray, 
clearListenerRegistry,  createActionChangeListener ,  createMenuChangeListener, 
createWinListener,  doClick,  ensurePopupMenuCreated,  f ireMenuCanceled, 
f ireMenuDeselected,  f ireMenuSelected,  getAccessibleContext,  getComponent,  getDelay, 
getltem,  getltemCount,  getMenuComponent,  getMenuComponentCount,  getMenuComponents , 
getPopupMenu,  getPopupMenuOrigin,  getSubElements,  getUIClassID,  insert,  insert, 
insert,  insertSeparator,  isMenuComponent,  isPopupMenuVisible,  isSelected,  isTearOff, 
isTopLevelMenu,  menuSelectionChanged,  pararaString,  processKeyEvent, 
registerMenuItemForAction,  remove,  remove,  remove,  removeAll,  removeMenuListener , 
igfat or ,  setDelav,  setMenuLocation,  setModel,  setPopupMenuVisible, 
setSelected,  translateToPopupMenu,  translateToPopupMenu, 

unregisterMenuItemForAction,  updateUI,  writeObject  _ __ _ _____ 


Methods  inherited  from  class  javax.swing.JMenuItem _ 

addMenuDragMouseListener,  addMenuKeyListener,  alwaysOnTop,  f ireMenuDragMouseDragged, 
fireMenuDragMouseEntered,  f ireMenuDragMouseExited,  f ireMenuDragMouseReleased,  ^ 
fireMenuKeyPressed,  fireMenuKeyReleased,  fireMenuKeyTyped,  getAccelerator,  init, 
isArmed,  processKeyEvent,  processMenuDragMouseEvent,  processMenuKeyEvent, 
processMouseEvent,  readObject,  removeMenuDragMouseListener,  removeMenuKeyListener, 
setArmed,  setEnabled,  setUI  _ _ _ _ _ _ 


Methods  inherited  from  class  javax.swing.AbstractButton _ _ _ _ 

addActionListener,  addChangeListener ,  addltemListener ,  checkHorizontalKey, 
checkVerticalKey,  createActionListener,  createChangeListener,  createltemListener, 
doClick,  f ireActionPerformed,  fireltemStateChanged,  f ireStateChanged,  _ 

getActionCommand,  getDisabledlcon,  getDisabledSelectedlcon,  getHorizontalAlignment, 
get HorizontalText Posit ion,  getlcon,  getLabel,  getMargin,  getMnemonic,  getModel, 
qet Pres sedl con,  getRolloverlcon,  getRolloverSelectedlcon,  getSelectedlcon, 
getSelectedObjects,  getText,  getUI,  getVerticalAlignment,  getVerticalTextPosition, 
isBorderPainted,  isContentAreaFilled,  isFocusPaxnted,  isRolloverEnabled, 
paintBorder,  removeActionListener,  removeChangeListener,  removeltemListener, 
setActionCommand,  setBorderPainted,  setContentAreaFilled,  setDisabledlcon, 
setDisabledSelectedlcon,  setFocusPainted,  setHorizontalAlignment, 

set HorizontalText Posit ion,  setlcon,  setLabel,  setMargin,  setMnemomc,  setMnemonic, 
setPressedlcon,  setRolloverEnabled,  setRolloverlcon,  setRolloverSelectedlcon, 
setSelectedlcon,  setText,  setOI,  setVerticalAlignment ,  setVerticalTextPosition 
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Methods  inherited  from  class  javax.swing.JComponent 

_paint Immediately,  addAncestorListener ,  addNotify,  addPropertyChangeListener, 
addPropertyChangeListener,  addVetoableChangeListener,  adjust Paint Flags, 
bindingFor Keystroke,  checklfChildObscuredBySibling,  computeVisibleRect , 
computeVisibleRect ,  contains,  createToolTip,  enableSerialization, 
f irePropertyChange,  f ire Proper tyChange,  f irePropertyChange,  firePropertyChange, 
firePropertyChange,  firePropertyChange,  firePropertyChange,  firePropertyChange, 
firePropertyChange,  f ireVetoableChange,  getActionForKeyStroke,  getAlignmentX, 
getAlignmentY,  get Autoscrolls,  get Border,  getBounds,  getClient Properties, 
get Client Property,  getComponent Graphics,  getConditionForKeyStroke, 
get DebugGraphicsOpt ions,  getFlag,  getGraphics,  getHeight,  getlnsets,  getlnsets, 
get Location,  getMaximumSize,  getMinimumSize,  get Next Focus ableComponent , 
get Pre f er redS ize,  getRegisteredKeyStrokes,  get Root Pane,  getSize,  getToolTipLocation, 
getToolTipText ,  getToolTipText ,  getTopLevelAncestor,  getVisibleRect ,  getWidth,  getX, 
getY,  grabFocus,  hasFocus,  isDoubleBuf fered,  isFocusCycleRoot ,  isFocusTraversable, 
isLightweightComponent ,  isManagingFocus,  isOpaque,  isOptimizedDrawingEnabled, 
isPaintingTile,  isRequestFocusEnabled,  isValidateRoot ,  keyboardBindings,  paint, 
paintChildren,  paint Component ,  paint Immediately,  paint Immediately,  paintWithBuf fer , 
processComponentKeyEvent ,  processFocusEvent ,  processKeyBinding,  processKeyBindings, 
processKeyBindingsForAUComponents,  processMouseMotionEvent ,  putClient Property, 
rectanglelsObscured,  rectanglelsObscuredBySibling,  registerKeyboardAction, 
registerKeyboardAction,  registerWithKeyboardManager,  removeAncestorListener, 
removeNotify,  removePropertyChangeListener ,  removePropertyChangeListener, 
removeVetoableChangeListener,  repaint,  repaint,  request Default Focus,  request Focus, 
res etKeyboardAct ions ,  reshape,  revalidate,  scrollRectToVisible,  setAlignmentX, 
set Alignment Y,  setAutoscrolls,  set Background,  set Border,  set DebugGraphicsOpt ions, 
setDoubleBuf fered,  setFlag,  setFont,  setForeground,  setMaximumSize,  setMinimumSize, 
setNextFocusableComponent ,  setOpaque,  set Paint ingChild,  setPreferredSize, 
setRequestFocusEnabled,  setToolTipText ,  setUI ,  set Visible,  shouldDebugGraphics , 
super ProcessMouseMotionEvent,  unregisterKeyboardAction, 
unregisterWithKeyboardManager,  update 


Methods  inherited  from  class  java.awt.  Container 

add,  add,  add,  add,  addContainerListener,  addlmpl,  applyOrientation, 
count Components,  deliverEvent ,  di spat chE vent Impl,  di spat chE vent ToSelf ,  doLayout , 
eventEnabled,  f indComponentAt ,  f indComponentAt ,  getComponent ,  getComponentAt , 
getComponent At,  getComponentCount ,  getComponents__NoClientCode,  getComponent s, 
getCursorTarget ,  getLayout,  getMouseEventTarget ,  getWindow,  initIDs,  insets, 
invalidate,  invalidateTree, . isAncestorOf ,  layout,  lightweightPrint ,  list,  list, 
locate,  minimumSize,  next Focus,  paintComponents,  postProcessKeyEvent , 
postsOldMouseE vents ,  pref erredSize ,  pre Process KeyE vent ,  print ,  printComponent s , 
printOneComponent ,  processContainerEvent ,  processEvent ,  proxyEnableEvents, 
proxyRequest Focus,  removeContainerListener,  setCursor,  setFocusOwner ,  setLayout , 
transfer Focus,  updateCursor ,  validate,  validateTree 
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Methods  inherited  from  class  java.awt.Component _ 

action,  add,  addComponentListener,  addFocu'sListener,  addlnputMethodListener, 
addKeyListener,  addMouseListener ,  addMouseMotionListener ,  arelnputMethodsEnabled, 
bounds,  checklmage,  checklmage,  coalesceEvents,  constructComponentName,  contains, 
createlmage,  createlmage,  disable,  disableEvents,  dispatchEvent,  enable,  enable, 
enableEvents ,  enablelnputMethods,  getBackground,  getBounds,  getColorModel, 
getComponentOrientation,  getCursor,  getDropTarget,  getFont_NoClientCode,  getFont, 
getFontMetrics,  getForeground,  getlnputContext,  getlnputMethodRequests, 
getlntrinsicCursor,  getLocale,  getLocation,  getLocationOnScreen,  getName, 
getNativeContainer,  getParent_NoClientCode,  getParent,  getPeer,  getSize,  getToolkit, 
getToolkitlmpl,  getTreeLock,  getWindowForObject,  gotFocus,  handleEvent,  hide, 
imageUpdate,  inside,  isDisplayable,  isEnabled,  isEnabledlmpl,  isLightweight, 
isShowing,  isValid,  isVisible,  keyDown,  keyUp,  list,  list,  list,  location, 
lostFocus,  mouseDown,  mouseDrag,  mouseEnter,  mouseExit,  mouseMove,  mouseUp,  move, 
nextFocus,  paintAll,  postEvent,  preparelmage,  preparelmage,  printAll, 
processComponentEvent,  processInputMethodEvent,  processMouseEvent,  remove, 
removeComponentListener,  removeFocusListener,  removelnputMethodListener, 
removeKeyListener,  removeMouseListener,  removeMouseMotionListener,  repaint,  repaint, 
repaint,  resize,  resize,  setBounds,  se-tBounds,  setComponentOrientation, 
setDropTarget,  setLocale,  setLocation,  setLocation,  setName,  setSize,  setSize,  show, 
show,  size,  toString,  transferFocus  _ 


Methods  inherited  from  class  java.lang.Object _ _ _ 

clone,  equals,  finalize,  getClass,  hashCode,  notify,  notifyAll,  registerNatives, 
wait,  wait,  wait  _ 


Field  Detail 


newMenuItem 

private  javax. swing. JMenuItem  newMenuItem 

Initiates  the  'New'  event 


openMenuItem 

private  javax. swing. JMenuItem  openMenuItem 

Initiates  the  'Open'  event 


commitWorkMenuItem 

private  javax. swing . JMenuItem  commitWorkMenuItem 

Initiates  the  'Commit  Work'  event 
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retrieveMenuItem 


private  j avax . swing . JMenuItem  retrieveMenuItem 

Initiates  the  'Retrieve  From  DDB'  event 


quitMenuItem 

private  j avax . swing . JMenuItem  quitMenuItem 

Initiates  the  'Quit'  event 


ownerWindow 

protected  caps . CAPSMain. CAPSMainWindow  ownerWindow 

The  main  window  which  owns  this  menu. 


Constructor  Detail 


PrototypeMenu 

public  PrototypeMenu (caps . CAPSMain . CAPSMainWindow  owner) 

Constructor  for  this  class. 

Parameters: 

owner  -  The  main  window  which  has  created  this  menu. 


Method  Detail 


actionPerformed 

public  void  actionPerformed ( java . awt. event .ActionEvent  e) 

Action  event  handler  for  the  menu  events. 

Specified  by: 

actionPerformed  in  interface  java.awt.event.ActionListener 

Parameters: 

e  -  The  action  event  that  is  created  by  selecting  a  menu  item  from  this  menu 


processNewMenuItem 

public  void  processNewMenuItem ( ) 
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Handles  the  event  which  is  caused  by  selecting  the  'New'  menu  item. 


processOpenMenuItem 

public  void  processOpenMenuItem ( ) 

Handles  the  event  which  is  caused  by  selecting  the  'Open'  menu  item. 


processCommitWorkMenuItem 

public  void  processCommitWorkMenuItem  ( ) 

Handles  the  event  which  is  caused  by  selecting  the  'Commit'  menu  item. 


Tree  Deprecated  Index  Help 

PREV  CLASS  NEXT  CLASS  FRAMES  NO  FRAMES 

SUMMARY:  INNER  |  FIELD  |  CONSTR  |  METHOD 


Class 


DETAIL:  FIELD  |  CONSTR  |  METHOD 


APPENDIX  E:  ACRONYMS 


CAPS 

Computer  Aided  Prototyping  System 

CASE 

Computer  Aided  Software  Engineering 

CDR 

Common  Data  Representation 

CGI 

Common  Gateway  Interface 

CORBA 

Common  Object  Request  Broker  Architecture 

CPL 

Common  Prototyping  Language 

DCOM 

Distributed  Component  Object  Model 

Dll 

Dynamic  Invocation  Interface 

Dll  COE 

Defense  Information  Infrastructure  Common  Operating  Environment 

DOD 

Department  of  Defense 

DSI 

Dynamic  Skeleton  Interface 

GAMBITS 

Graphical  Approach  to  Modeling  and  Building  Interactively  a 

Technical  System 

GUI 

graphical  user  interface 

HIS 

Heterogeneous  Systems  Integrator 

HTTP 

Hypertext  Transfer  Protocol 

IDE 

integrated  development  environments 

IDL 

Interface  Definition  Language 

JDK 

Java  Developer  Kit 

JDS 

Jackson  Development  System 

JVM 

Java  Virtual  Machine 

LAN 

local  area  network 

OMA 

Object  Management  Architecture 

OMG 

Object  Management  Group 

ORB 

Object  Request  Broker 

PC 

personal  computer 

PROTOTECH 

Prototyping  Technology 

PSDL 

Prototype  System  Design  Language 

RaPIER 

Rapid  Prototyping  to  Investigate  End-user  Requirements 

RMI 

Remote  Method  Invocations 

RPC 

remote  procedure  call 

SSDL 

System  Specification  and  Design  Language 

UML 

Unified  Modeling  Language 

WAN 

wide  area  network 

WWW 

World  Wide  Web 
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